home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Turnbull China Bikeride
/
Turnbull China Bikeride - Disc 1.iso
/
ARGONET
/
PD
/
PROGRAMMING
/
G77.ZIP
/
!gcc
/
docs
/
fortran
/
g77
(
.txt
)
< prev
Wrap
GNU Info File
|
1996-11-11
|
391KB
|
6,964 lines
This is Info file ^.!gcc.docs.fortran.g77, produced by Makeinfo-1.63
from the input file texi.g77.
This file explains how to use the GNU Fortran system.
Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA
Copyright (C) 1995, 1996 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.
Contributed by James Craig Burley (`burley@gnu.ai.mit.edu').
Inspired by a first pass at translating `g77-0.5.16/f/DOC' that was
contributed to Craig by David Ronis (`ronis@onsager.chem.mcgill.ca').
File: ^.!gcc.docs.fortran.g77, Node: Top, Next: Copying, Up: (DIR)
Introduction
************
This manual documents how to run and install the GNU Fortran
compiler, as well as its new features and incompatibilities, and how to
report bugs. It corresponds to GNU Fortran version 0.5.18.
* Menu:
* Copying:: GNU General Public License says
how you can copy and share GNU Fortran.
* Contributors:: People who have contributed to GNU Fortran.
* Funding:: How to help assure continued work for free software.
* Funding GNU Fortran:: How to help assure continued work on GNU Fortran.
* Look and Feel:: Protect your freedom--fight "look and feel".
* Getting Started:: Finding your way around this manual.
* What is GNU Fortran?:: How `g77' fits into the universe.
* G77 and GCC:: You can compile Fortran, C, or other programs.
* Invoking G77:: Command options supported by `g77'.
* News:: News about recent releases of `g77'.
* Changes:: User-visible changes to recent releases of `g77'.
* Language:: The GNU Fortran language.
* Installation:: How to configure, compile and install GNU Fortran.
* Debugging and Interfacing:: How `g77' generates code.
* Collected Fortran Wisdom:: How to avoid Trouble.
* Trouble:: If you have trouble with GNU Fortran.
* Open Questions:: Things we'd like to know.
* Bugs:: How, why, and where to report bugs.
* Service:: How to find suppliers of support for GNU Fortran.
* Index:: Index of concepts and symbol names.
File: ^.!gcc.docs.fortran.g77, Node: Copying, Next: Contributors, Prev: Top, Up: Top
GNU GENERAL PUBLIC LICENSE
**************************
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
========
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it in
new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software,
and (2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains a
notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program",
below, refers to any such program or work, and a "work based on
the Program" means either the Program or any derivative work under
copyright law: that is to say, a work containing the Program or a
portion of it, either verbatim or with modifications and/or
translated into another language. (Hereinafter, translation is
included without limitation in the term "modification".) Each
licensee is addressed as "you".
Activities other than copying, distribution and modification are
not covered by this License; they are outside its scope. The act
of running the Program is not restricted, and the output from the
Program is covered only if its contents constitute a work based on
the Program (independent of having been made by running the
Program). Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any
warranty; and give any other recipients of the Program a copy of
this License along with the Program.
You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange
for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a. You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b. You must cause any work that you distribute or publish, that
in whole or in part contains or is derived from the Program
or any part thereof, to be licensed as a whole at no charge
to all third parties under the terms of this License.
c. If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display
an announcement including an appropriate copyright notice and
a notice that there is no warranty (or else, saying that you
provide a warranty) and that users may redistribute the
program under these conditions, and telling the user how to
view a copy of this License. (Exception: if the Program
itself is interactive but does not normally print such an
announcement, your work based on the Program is not required
to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and separate
works in themselves, then this License, and its terms, do not
apply to those sections when you distribute them as separate
works. But when you distribute the same sections as part of a
whole which is a work based on the Program, the distribution of
the whole must be on the terms of this License, whose permissions
for other licensees extend to the entire whole, and thus to each
and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or
contest your rights to work written entirely by you; rather, the
intent is to exercise the right to control the distribution of
derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the
Program with the Program (or with a work based on the Program) on
a volume of a storage or distribution medium does not bring the
other work under the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms
of Sections 1 and 2 above provided that you also do one of the
following:
a. Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of
Sections 1 and 2 above on a medium customarily used for
software interchange; or,
b. Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a
medium customarily used for software interchange; or,
c. Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with
such an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete
source code means all the source code for all modules it contains,
plus any associated interface definition files, plus the scripts
used to control compilation and installation of the executable.
However, as a special exception, the source code distributed need
not include anything that is normally distributed (in either
source or binary form) with the major components (compiler,
kernel, and so on) of the operating system on which the executable
runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this
License. However, parties who have received copies, or rights,
from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify
or distribute the Program or its derivative works. These actions
are prohibited by law if you do not accept this License.
Therefore, by modifying or distributing the Program (or any work
based on the Program), you indicate your acceptance of this
License to do so, and all its terms and conditions for copying,
distributing or modifying the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program
subject to these terms and conditions. You may not impose any
further restrictions on the recipients' exercise of the rights
granted herein. You are not responsible for enforcing compliance
by third parties to this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent
issues), conditions are imposed on you (whether by court order,
agreement or otherwise) that contradict the conditions of this
License, they do not excuse you from the conditions of this
License. If you cannot distribute so as to satisfy simultaneously
your obligations under this License and any other pertinent
obligations, then as a consequence you may not distribute the
Program at all. For example, if a patent license would not permit
royalty-free redistribution of the Program by all those who
receive copies directly or indirectly through you, then the only
way you could satisfy both it and this License would be to refrain
entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable
under any particular circumstance, the balance of the section is
intended to apply and the section as a whole is intended to apply
in other circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of
any such claims; this section has the sole purpose of protecting
the integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is
willing to distribute software through any other system and a
licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed
to be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces,
the original copyright holder who places the Program under this
License may add an explicit geographical distribution limitation
excluding those countries, so that distribution is permitted only
in or among countries not thus excluded. In such case, this
License incorporates the limitation as if written in the body of
this License.
9. The Free Software Foundation may publish revised and/or new
versions of the General Public License from time to time. Such
new versions will be similar in spirit to the present version, but
may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the
Program specifies a version number of this License which applies
to it and "any later version", you have the option of following
the terms and conditions either of that version or of any later
version published by the Free Software Foundation. If the Program
does not specify a version number of this License, you may choose
any version ever published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the
author to ask for permission. For software which is copyrighted
by the Free Software Foundation, write to the Free Software
Foundation; we sometimes make exceptions for this. Our decision
will be guided by the two goals of preserving the free status of
all derivatives of our free software and of promoting the sharing
and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE
QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
=============================================
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these
terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
Copyright (C) 19YY NAME OF AUTHOR
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
Also add information on how to contact you by electronic and paper
mail.
If the program is interactive, make it output a short notice like
this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19YY NAME OF AUTHOR
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the
appropriate parts of the General Public License. Of course, the
commands you use may be called something other than `show w' and `show
c'; they could even be mouse-clicks or menu items--whatever suits your
program.
You should also get your employer (if you work as a programmer) or
your school, if any, to sign a "copyright disclaimer" for the program,
if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
SIGNATURE OF TY COON, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your
program into proprietary programs. If your program is a subroutine
library, you may consider it more useful to permit linking proprietary
applications with the library. If this is what you want to do, use the
GNU Library General Public License instead of this License.
File: ^.!gcc.docs.fortran.g77, Node: Contributors, Next: Funding, Prev: Copying, Up: Top
Contributors to GNU Fortran
***************************
In addition to James Craig Burley, who wrote the front end, many
people have helped create and improve GNU Fortran.
* The packaging and compiler portions of GNU Fortran are based
largely on the GNU CC compiler. *Note Contributors to GNU CC:
(gcc)Contributors, for more information.
* The run-time library used by GNU Fortran is a minor repackaging of
the `libf2c' library (combined from the `libF77' and `libI77'
libraries) provided as part of `f2c', available for free from
`netlib' sites on the Internet.
* Cygnus Support and The Free Software Foundation contributed
significant money and/or equipment to Craig's efforts.
* The following individuals served as alpha testers prior to `g77''s
public release. This work consisted of testing, researching,
sometimes debugging, and occasionally providing small amounts of
code and fixes for `g77', plus offering plenty of helpful advice
to Craig:
Jonathan Corbet
Dr. Mark Fernyhough
Takafumi Hayashi (The University of
AIzu)--`takafumi@u-aizu.ac.jp'
Kate Hedstrom
Michel Kern (INRIA and Rice
University)--`Michel.Kern@inria.fr'
Dr. A. O. V. Le Blanc
Dave Love
Rick Lutowski
Toon Moene
Rick Niles
Derk Reefman
Wayne K. Schroll
Bill Thorson
Pedro A. M. Vazquez
Ian Watson
* Scott Snyder (`snyder@d0sgif.fnal.gov') provided the patch to add
rudimentary support for `INTEGER*1', `INTEGER*2', and `LOGICAL*1'.
This inspired Craig to add further support, even though the
resulting support would still be incomplete, because version 0.6
is still a ways off.
* David Ronis (`ronis@onsager.chem.mcgill.ca') inspired and
encouraged Craig to rewrite the documentation in texinfo format by
contributing a first pass at a translation of the old
`g77-0.5.16/f/DOC' file.
* Toon Moene (`toon@moene.indiv.nluug.nl') performed some analysis
of generated code as part of an overall project to improve `g77'
code generation to at least be as good as `f2c' used in
conjunction with `gcc'. So far, this has resulted in the three,
somewhat experimental, options added by `g77' to the `gcc'
compiler and its back end.
* Many other individuals have helped debug, test, and improve `g77'
over the past several years, and undoubtedly more people will be
doing so in the future. If you have done so, and would like to
see your name listed in the above list, please ask! The default
is that people wish to remain anonymous.
File: ^.!gcc.docs.fortran.g77, Node: Funding, Next: Funding GNU Fortran, Prev: Contributors, Up: Top
Funding Free Software
*********************
If you want to have more free software a few years from now, it makes
sense for you to help encourage people to contribute funds for its
development. The most effective approach known is to encourage
commercial redistributors to donate.
Users of free software systems can boost the pace of development by
encouraging for-a-fee distributors to donate part of their selling price
to free software developers--the Free Software Foundation, and others.
The way to convince distributors to do this is to demand it and
expect it from them. So when you compare distributors, judge them
partly by how much they give to free software development. Show
distributors they must compete to be the one who gives the most.
To make this approach work, you must insist on numbers that you can
compare, such as, "We will donate ten dollars to the Frobnitz project
for each disk sold." Don't be satisfied with a vague promise, such as
"A portion of the profits are donated," since it doesn't give a basis
for comparison.
Even a precise fraction "of the profits from this disk" is not very
meaningful, since creative accounting and unrelated business decisions
can greatly alter what fraction of the sales price counts as profit.
If the price you pay is $50, ten percent of the profit is probably less
than a dollar; it might be a few cents, or nothing at all.
Some redistributors do development work themselves. This is useful
too; but to keep everyone honest, you need to inquire how much they do,
and what kind. Some kinds of development make much more long-term
difference than others. For example, maintaining a separate version of
a program contributes very little; maintaining the standard version of a
program for the whole community contributes much. Easy new ports
contribute little, since someone else would surely do them; difficult
ports such as adding a new CPU to the GNU C compiler contribute more;
major new features or packages contribute the most.
By establishing the idea that supporting further development is "the
proper thing to do" when distributing free software for a fee, we can
assure a steady flow of resources into making more free software.
Copyright (C) 1994 Free Software Foundation, Inc.
Verbatim copying and redistribution of this section is permitted
without royalty; alteration is not permitted.
File: ^.!gcc.docs.fortran.g77, Node: Funding GNU Fortran, Next: Look and Feel, Prev: Funding, Up: Top
Funding GNU Fortran
*******************
Work on GNU Fortran is still being done mostly by its author, James
Craig Burley (`burley@gnu.ai.mit.edu'), who is a volunteer for, not an
employee of, the Free Software Foundation (FSF). As with other GNU
software, funding is important because it can pay for needed equipment,
personnel, and so on.
The FSF provides information on the best way to fund ongoing
development of GNU software (such as GNU Fortran) in documents such as
the "GNUS Bulletin". Email `gnu@prep.ai.mit.edu' for information on
funding the FSF.
To fund specific GNU Fortran work in particular, the FSF might
provide a means for that, but the FSF does not provide direct funding
to the author of GNU Fortran to continue his work. The FSF has
employee salary restrictions that can be incompatible with the
financial needs of some volunteers, who therefore choose to remain
volunteers and thus be able to be free to do contract work and
otherwise make their own schedules for doing GNU work.
Still, funding the FSF at least indirectly benefits work on specific
projects like GNU Fortran because it ensures the continuing operation
of the FSF offices, their workstations, their network connections, and
so on, which are invaluable to volunteers. (Similarly, hiring Cygnus
Support can help a project like GNU Fortran--Cygnus has been a
long-time donor of equipment usage to the author of GNU Fortran, and
this too has been invaluable--*Note Contributors::.)
Currently, the only way to directly fund the author of GNU Fortran
in his work on that project is to hire him for the work you want him to
do, or donate money to him. Several people have done this already,
with the result that he has not needed to immediately find contract
work on a few occasions. If more people did this, he would be able to
plan on not doing contract work for many months and could thus devote
that time to work on projects (such as the planned changes for
`g77-0.6') that require longer timeframes to complete. For the latest
information on the status of the author, do `finger -l
burley@gnu.ai.mit.edu', i.e. access `burley''s `.plan' file just as you
would `fortran''s to get `g77' status (except there's no public `ftp'
access to `burley''s `.plan' file--you can email him asking for it).
Another important way to support work on GNU Fortran is to volunteer
to help out. Work is needed on documentation, testing, porting to
various machines, and in some cases, coding (although major changes
planned for version 0.6 make it difficult to add manpower to this area).
Email `fortran@gnu.ai.mit.edu' to volunteer for this work.
*Note Funding Free Software: Funding, for more information.
File: ^.!gcc.docs.fortran.g77, Node: Look and Feel, Next: Getting Started, Prev: Funding GNU Fortran, Up: Top
Protect Your Freedom--Fight "Look And Feel"
*******************************************
To preserve the ability to write free software, including
replacements for proprietary software, authors must be free to
replicate the user interface to which users of existing software have
become accustomed.
*Note Protect Your Freedom--Fight "Look And Feel": (gcc)Look and
Feel, for more information.
File: ^.!gcc.docs.fortran.g77, Node: Getting Started, Next: What is GNU Fortran?, Prev: Look and Feel, Up: Top
Getting Started
***************
If you don't need help getting started reading the portions of this
manual that are most important to you, you should skip this portion of
the manual.
If you are new to compilers, especially Fortran compilers, or new to
how compilers are structured under UNIX and UNIX-like systems, you'll
want to see *Note What is GNU Fortran?::.
If you are new to GNU compilers, or have used only one GNU compiler
in the past and not had to delve into how it lets you manage various
versions and configurations of `gcc', you should see *Note G77 and
GCC::.
Everyone except experienced `g77' users should see *Note Invoking
G77::.
If you're acquainted with previous versions of `g77', you should see
*Note News::. Further, if you've actually used previous versions of
`g77', especially if you've written or modified Fortran code to be
compiled by previous versions of `g77', you should see *Note Changes::.
If you intend to write or otherwise compile code that is not already
strictly conforming ANSI FORTRAN 77--and this is probably everyone--you
should see *Note Language::.
If you don't already have `g77' installed on your system, you must
see *Note Installation::.
If you run into trouble getting Fortran code to compile, link, run,
or work properly, you might find answers if you see *Note Debugging and
Interfacing::, see *Note Collected Fortran Wisdom::, and see *Note
Trouble::. You might also find that the problems you are encountering
are bugs in `g77'--see *Note Bugs::, for information on reporting them,
after reading the other material.
If you need further help with `g77', or with freely redistributable
software in general, see *Note Service::.
If you would like to help the `g77' project, see *Note Funding GNU
Fortran::, for information on helping financially, and see *Note
Projects::, for information on helping in other ways.
If you're generally curious about the future of `g77', see *Note
Projects::. If you're curious about its past, see *Note Contributors::,
and see *Note Funding GNU Fortran::.
To see a few of the questions maintainers of `g77' have, and that
you might be able to answer, see *Note Open Questions::.
File: ^.!gcc.docs.fortran.g77, Node: What is GNU Fortran?, Next: G77 and GCC, Prev: Getting Started, Up: Top
What is GNU Fortran?
********************
GNU Fortran, or `g77', is designed initially as a free replacement
for, or alternative to, the UNIX `f77' command. (Similarly, `gcc' is
designed as a replacement for the UNIX `cc' command.)
`g77' also is designed to fit in well with the other fine GNU
compilers and tools.
Sometimes these design goals conflict--in such cases, resolution
often is made in favor of fitting in well with Project GNU. These
cases are usually identified in the appropriate sections of this manual.
As compilers, `g77', `gcc', and `f77' share the following
characteristics:
* They read a user's program, stored in a file and containing
instructions written in the appropriate language (Fortran, C, and
so on). This file contains "source code".
* They translate the user's program into instructions a computer can
carry out more quickly than it takes to translate the instructions
in the first place. These instructions are called "machine
code"--code designed to be efficiently translated and processed by
a machine such as a computer. Humans usually aren't as good
writing machine code as they are at writing Fortran or C, because
it is easy to make tiny mistakes writing machine code. When
writing Fortran or C, it is easy to make big mistakes.
* They provide information in the generated machine code that can
make it easier to find bugs in the program (using a debugging
tool, called a "debugger", such as `gdb').
* They locate and gather machine code already generated to perform
actions requested by statements in the user's program. This
machine code is organized into "libraries" and is located and
gathered during the "link" phase of the compilation process.
(Linking often is thought of as a separate step, because it can be
directly invoked via the `ld' command. However, the `g77' and
`gcc' commands, as with most compiler commands, automatically
perform the linking step by calling on `ld' directly, unless asked
to not do so by the user.)
* They attempt to diagnose cases where the user's program contains
incorrect usages of the language. The "diagnostics" produced by
the compiler indicate the problem and the location in the user's
source file where the problem was first noticed. The user can use
this information to locate and fix the problem. (Sometimes an
incorrect usage of the language leads to a situation where the
compiler can no longer make any sense of what follows--while a
human might be able to--and thus ends up complaining about many
"problems" it encounters that, in fact, stem from just one
problem, usually the first one reported.)
* They attempt to diagnose cases where the user's program contains a
correct usage of the language, but instructs the computer to do
something questionable. These diagnostics often are in the form
of "warnings", instead of the "errors" that indicate incorrect
usage of the language.
How these actions are performed is generally under the control of
the user. Using command-line options, the user can specify how
persnickety the compiler is to be regarding the program (whether to
diagnose questionable usage of the language), how much time to spend
making the generated machine code run faster, and so on.
`g77' consists of several components:
* A modified version of the `gcc' command, which also might be
installed as the system's `cc' command. (In many cases, `cc'
refers to the system's "native" C compiler, which might be a
non-GNU compiler, or an older version of `gcc' considered more
stable or that is used to build the operating system kernel.)
* The `g77' command itself, which also might be installed as the
system's `f77' command.
* The `libf2c' run-time library. This library contains the machine
code needed to support capabilities of the Fortran language that
are not directly provided by the machine code generated by the
`g77' compilation phase.
* The compiler itself, internally named `f771'.
Note that `f771' does not generate machine code directly--it
generates "assembly code" that is a more readable form of machine
code, leaving the conversion to actual machine code to an
"assembler", usually named `as'.
`gcc' is often thought of as "the C compiler" only, but it does more
than that. Based on command-line options and the names given for files
on the command line, `gcc' determines which actions to perform,
including preprocessing, compiling (in a variety of possible
languages), assembling, and linking.
For example, the command `gcc foo.c' "drives" the file `foo.c'
through the preprocessor `cpp', then the C compiler (internally named
`cc1'), then the assembler (usually `as'), then the linker (`ld'),
producing an executable program named `a.out' (on UNIX systems).
As another example, the command `gcc foo.cc' would do much the same
as `gcc foo.c', but instead of using the C compiler named `cc1', `gcc'
would use the C++ compiler (named `cc1plus').
In a GNU Fortran installation, `gcc' recognizes Fortran source files
by name just like it does C and C++ source files. It knows to use the
Fortran compiler named `f771', instead of `cc1' or `cc1plus', to
compile Fortran files.
Non-Fortran-related operation of `gcc' is generally unaffected by
installing the GNU Fortran version of `gcc'. However, without the
installed version of `gcc' being the GNU Fortran version, `gcc' will
not be able to compile and link Fortran programs--and since `g77' uses
`gcc' to do most of the actual work, neither will `g77'!
The `g77' command is essentially just a front-end for the `gcc'
command. Fortran users will normally use `g77' instead of `gcc',
because `g77' knows how to specify the libraries needed to link with
Fortran programs (`libf2c' and `lm'). `g77' can still compile and link
programs and source files written in other languages, just like `gcc'.
The command `g77 -v' is a quick way to display lots of version
information for the various programs used to compile a typical
preprocessed Fortran source file--this produces much more output than
`gcc -v' currently does. (It also produces an error message near the
end of the output, a diagnostic from the linker, usually `ld'--you can
safely ignore this error, but do include the entire output with any bug
report you submit.) In the output of this command, the line beginning
`GNU Fortran Front End' identifies the version number of GNU Fortran;
immediately preceding that line is a line identifying the version of
`gcc' with which that version of `g77' was built.
The `libf2c' library is distributed with GNU Fortran for the
convenience of its users, but is not part of GNU Fortran. It contains
the procedures needed by Fortran programs while they are running.
For example, while code generated by `g77' is likely to do
additions, subtractions, and multiplications "in line"--in the actual
compiled code--it is not likely to do trigonometric functions this way.
Instead, operations like trigonometric functions are compiled by the
`f771' compiler (invoked by `g77' when compiling Fortran code) into
machine code that, when run, calls on functions in `libf2c', so
`libf2c' must be linked with almost every useful program having any
component compiled by GNU Fortran. (As mentioned above, the `g77'
command takes care of all this for you.)
The `f771' program represents most of what is unique to GNU Fortran.
While the `libf2c' component is really part of `f2c', a free
Fortran-to-C converter distributed by Bellcore (AT&T), and the `g77'
command is just a small front-end to `gcc', `f771' is a combination of
two rather large chunks of code.
One chunk is the so-called "GNU Back End", or GBE, which knows how
to generate fast code for a wide variety of processors. The same GBE
is used by the C, C++, and Fortran compiler programs `cc1', `cc1plus',
and `f771', plus others. Often the GBE is referred to as the "gcc back
end" or even just "gcc"--in this manual, the term GBE is used whenever
the distinction is important.
The other chunk of `f771' is the majority of what is unique about
GNU Fortran--the code that knows how to interpret Fortran programs to
determine what they are intending to do, and then communicate that
knowledge to the GBE for actual compilation of those programs. This
chunk is called the "Fortran Front End" (FFE). The `cc1' and `cc1plus'
programs have their own front ends, for the C and C++ languages,
respectively. These fronts ends are responsible for diagnosing
incorrect usage of their respective languages by the programs the
process, and are responsible for most of the warnings about
questionable constructs as well. (The GBE handles producing some
warnings, like those concerning possible references to undefined
variables.)
Because so much is shared among the compilers for various languages,
much of the behavior and many of the user-selectable options for these
compilers are similar. For example, diagnostics (error messages and
warnings) are similar in appearance; command-line options like `-Wall'
have generally similar effects; and the quality of generated code (in
terms of speed and size) is roughly similar (since that work is done by
the shared GBE).
File: ^.!gcc.docs.fortran.g77, Node: G77 and GCC, Next: Invoking G77, Prev: What is GNU Fortran?, Up: Top
Compile Fortran, C, or Other Programs
*************************************
A GNU Fortran installation includes a modified version of the `gcc'
command.
In a non-Fortran installation, `gcc' recognizes C, C++, and
Objective-C source files.
In a GNU Fortran installation, `gcc' also recognizes Fortran source
files and accepts Fortran-specific command-line options, plus some
command-line options that are designed to cater to Fortran users but
apply to other languages as well.
*Note Compile C; C++; or Objective-C: (gcc)G++ and GCC, for
information on the way different languages are handled by the GNU CC
compiler (`gcc').
Also provided as part of GNU Fortran is the `g77' command. The
`g77' command is designed to make compiling and linking Fortran
programs somewhat easier than when using the `gcc' command for these
tasks. It does this by analyzing the command line somewhat and
changing it appropriately before submitting it to the `gcc' command.
Use the `-v' option with `g77' to see what is going on--the first
line of output is the invocation of the `gcc' command. Use
`--driver=true' to disable actual invocation of `gcc' (this works
because `true' is the name of a UNIX command that simply returns
success status).
File: ^.!gcc.docs.fortran.g77, Node: Invoking G77, Next: News, Prev: G77 and GCC, Up: Top
GNU Fortran Command Options
***************************
The `g77' command supports all the options supported by the `gcc'
command. *Note GNU CC Command Options: (gcc)Invoking GCC, for
information on the non-Fortran-specific aspects of the `gcc' command
(and, therefore, the `g77' command).
The `g77' command supports one option not supported by the `gcc'
command:
`--driver=COMMAND'
Specifies that COMMAND, rather than `gcc', is to be invoked by
`g77' to do its job. For example, within the gcc build directory
after building GNU Fortran (but without having to install it),
`./g77 --driver=./xgcc foo.f -B./'.
All other options are supported both by `g77' and by `gcc' as
modified (and reinstalled) by the `g77' distribution. In some cases,
options have positive and negative forms; the negative form of `-ffoo'
would be `-fno-foo'. This manual documents only one of these two
forms, whichever one is not the default.
* Menu:
* Option Summary:: Brief list of all `g77' options,
without explanations.
* Overall Options:: Controlling the kind of output:
an executable, object files, assembler files,
or preprocessed source.
* Fortran Dialect Options:: Controlling the variant of Fortran language
compiled.
* Warning Options:: How picky should the compiler be?
* Debugging Options:: Symbol tables, measurements, and debugging dumps.
* Optimize Options:: How much optimization?
* Preprocessor Options:: Controlling header files and macro definitions.
Also, getting dependency information for Make.
* Directory Options:: Where to find header files and libraries.
Where to find the compiler executable files.
* Code Gen Options:: Specifying conventions for function calls, data layout
and register usage.
* Environment Variables:: Env vars that affect GNU Fortran.
File: ^.!gcc.docs.fortran.g77, Node: Option Summary, Next: Overall Options, Up: Invoking G77
Option Summary
==============
Here is a summary of all the options specific to GNU Fortran, grouped
by type. Explanations are in the following sections.
*Overall Options*
*Note Options Controlling the Kind of Output: Overall Options.
--driver -fversion -fset-g77-defaults
*Fortran Language Options*
*Note Options Controlling Fortran Dialect: Fortran Dialect Options.
-ffree-form -fno-fixed-form -ff90 -fvxt-not-f90
-ff90-not-vxt -fdollar-ok -fno-backslash
-fintrin-case-initcap -fintrin-case-upper
-fintrin-case-lower -fintrin-case-any
-fmatch-case-initcap -fmatch-case-upper
-fmatch-case-lower -fmatch-case-any
-fsource-case-upper -fsource-case-lower -fsource-case-preserve
-fsymbol-case-initcap -fsymbol-case-upper
-fsymbol-case-lower -fsymbol-case-any
-fcase-strict-upper -fcase-strict-lower
-fcase-initcap -fcase-upper -fcase-lower -fcase-preserve
-fdcp-intrinsics-delete -fdcp-intrinsics-hide
-fdcp-intrinsics-disable -fdcp-intrinsics-enable
-ff2c-intrinsics-delete -ff2c-intrinsics-hide
-ff2c-intrinsics-disable -ff2c-intrinsics-enable
-ff90-intrinsics-delete -ff90-intrinsics-hide
-ff90-intrinsics-disable -ff90-intrinsics-enable
-fmil-intrinsics-delete -fmil-intrinsics-hide
-fmil-intrinsics-disable -fmil-intrinsics-enable
-funix-intrinsics-delete -funix-intrinsics-hide
-funix-intrinsics-disable -funix-intrinsics-enable
-fvxt-intrinsics-delete -fvxt-intrinsics-hide
-fvxt-intrinsics-disable -fvxt-intrinsics-enable
-ffixed-line-length-N -ffixed-line-length-none
*Warning Options*
*Note Options to Request or Suppress Warnings: Warning Options.
-fsyntax-only -pedantic -pedantic-errors -fpedantic
-fugly -fno-ugly-args -fno-ugly-init -w -Wimplicit
-Wunused -Wuninitialized -Wall -Wsurprising -Werror
-W
*Debugging Options*
*Note Options for Debugging Your Program or GCC: Debugging Options.
-g
*Optimization Options*
*Note Options that Control Optimization: Optimize Options.
-ffloat-store -fforce-mem -fforce-addr -fno-inline
-ffast-math -fstrength-reduce -frerun-cse-after-loop
-fexpensive-optimizations -fdelayed-branch
-fschedule-insns -fschedule-insn2 -fcaller-saves
-funroll-loops -funroll-all-loops
-fno-move-all-movables -fno-reduce-all-givs
-fno-rerun-loop-opt
*Directory Options*
*Note Options for Directory Search: Directory Options.
-IDIR -I-
*Code Generation Options*
*Note Options for Code Generation Conventions: Code Gen Options.
-fno-automatic -finit-local-zero -fno-f2c
-ff2c-library -fno-underscoring -fno-ident
-fpcc-struct-return -freg-struct-return
-fshort-double -fno-common -fpack-struct
-fzeros
* Menu:
* Overall Options:: Controlling the kind of output:
an executable, object files, assembler files,
or preprocessed source.
* Fortran Dialect Options:: Controlling the variant of Fortran language
compiled.
* Warning Options:: How picky should the compiler be?
* Debugging Options:: Symbol tables, measurements, and debugging dumps.
* Optimize Options:: How much optimization?
* Preprocessor Options:: Controlling header files and macro definitions.
Also, getting dependency information for Make.
* Directory Options:: Where to find header files and libraries.
Where to find the compiler executable files.
* Code Gen Options:: Specifying conventions for function calls, data layout
and register usage.
File: ^.!gcc.docs.fortran.g77, Node: Overall Options, Next: Fortran Dialect Options, Prev: Option Summary, Up: Invoking G77
Options Controlling the Kind of Output
======================================
Compilation can involve as many as four stages: preprocessing,
compilation proper, assembly, and linking, always in that order. The
first three stages apply to an individual source file, and end by
producing an object file; linking combines all the object files (those
newly compiled, and those specified as input) into an executable file.
For any given input file, the file name suffix determines what kind
of compilation is done. Suffixes specific to GNU Fortran are listed
below. *Note gcc: (Using and Porting GNU CC)Overall Options, for
information on suffixes recognized by GNU CC.
`FILE.f'
`FILE.for'
Fortran source code that should not be preprocessed.
`FILE.F'
`FILE.fpp'
Fortran source code that must be preprocessed (by the C
preprocessor `cpp', which is part of GNU CC).
UNIX users typically use the `FILE.f' and `FILE.F' nomenclature.
Users of other operating systems, especially those that cannot
distinguish upper-case letters from lower-case letters in their file
names, typically use the `FILE.for' and `FILE.fpp' nomenclature.
Use of the preprocessor `cpp' allows use of C-like constructs such
as `#define' and `#include', but can lead to unexpected, even mistaken,
results due to Fortran's source file format. It is recommended that
use of the C preprocessor be limited to `#include' and, in conjunction
with `#define', only `#if' and related directives, thus avoiding
in-line macro expansion entirely. This recommendation applies
especially when using the traditional fixed source form. With free
source form, fewer unexpected transformations are likely to happen, but
use of Hollerith and things like continued character constants can
nevertheless present problems.
The following options that affect overall processing are recognized
by the `g77' and `gcc' commands in a GNU Fortran installation:
`--driver=COMMAND'
This works only when invoking the `g77' command, not when invoking
the `gcc' command. *Note GNU Fortran Command Options: Invoking
G77, for information on this option.
`-fversion'
Ensure that the `g77'-specific version of the compiler phase is
reported, if run. (This is supplied automatically when `-v' or
`--version' is specified as a command-line option for `g77' or
`gcc' and when the resulting commands compile Fortran source
files.)
`-fset-g77-defaults'
Set up whatever `gcc' options are to apply to Fortran compilations.
For version 0.5.18, this is equivalent to `-fmove-all-movables
-freduce-all-givs -frerun-loop-opt'. (This is supplied
automatically when compiling Fortran code. The description of
this option is here so that users seeing it in the output of, say,
`g77 -v' understand why it is there. Also, developers who run
`f771' directly might want to specify it by hand to get the same
defaults as they would running `f771' via `g77' or `gcc'.)
*Note Options Controlling the Kind of Output: (gcc)Overall Options,
for information on more options that control the overall operation of
the `gcc' command (and, by extension, the `g77' command).
File: ^.!gcc.docs.fortran.g77, Node: Fortran Dialect Options, Next: Warning Options, Prev: Overall Options, Up: Invoking G77
Options Controlling Fortran Dialect
===================================
The following options control the dialect of Fortran that the
compiler accepts:
`-ffree-form'
`-fno-fixed-form'
Specify that the source file is written in free form (introduced
in Fortran 90) instead of the more-traditional fixed form.
`-ff90'
Allow certain Fortran-90 constructs.
This option controls whether certain Fortran 90 constructs are
recognized. (Other Fortran 90 constructs might or might not be
recognized depending on other options such as `-fvxt-not-f90',
`-ff90-intrinsics-enable', and the current level of support for
Fortran 90.)
*Note GNU Fortran Extensions: Extensions, for more information.
`-fvxt-not-f90'
`-ff90-not-vxt'
Specify whether Fortran 90 or other popular extensions are to be
assumed for ambiguous constructs. The default is -fvxt-not-f90.
For example, with `-ff90-not-vxt', `PRINT *,"double-quoted
string"' is valid, while with `-fvxt-not-f90', `PRINT *,"2000' is
valid.
(There is no way to allow both constructs in the general case,
since statements like `PRINT *,"2000 !comment?"' would be
ambiguous.)
*Note GNU Fortran Dialects: Dialects, for more information.
`-fdollar-ok'
Allow `$' as a valid character in a symbol name.
`-fno-backslash'
Specify that `\' is not to be specially interpreted in character
and Hollerith constants a la C and many UNIX Fortran compilers.
For example, with `-fbackslash' in effect, `A\nB' specifies three
characters, with the second one being newline. With
`-fno-backslash', it specifies four characters, `A', `\', `n', and
`B'.
Note that `g77' implements a fairly general form of backslash
processing that is incompatible with the narrower forms supported
by some other compilers. For example, `'A\003B'' is a
three-character string in `g77', whereas other compilers that
support backslash might not support the three-octal-digit form,
and thus treat that string as longer than three characters.
*Note Certain Changes We Don't Want to Make: Non-bugs, for
information on why `-fbackslash' is the default instead of
`-fno-backslash'.
`-fintrin-case-initcap'
`-fintrin-case-upper'
`-fintrin-case-lower'
`-fintrin-case-any'
Specify expected case for intrinsic names. `-fintrin-case-lower'
is the default.
`-fmatch-case-initcap'
`-fmatch-case-upper'
`-fmatch-case-lower'
`-fmatch-case-any'
Specify expected case for keywords. `-fmatch-case-lower' is the
default.
`-fsource-case-upper'
`-fsource-case-lower'
`-fsource-case-preserve'
Specify whether source text other than character and Hollerith
constants is to be translated to uppercase, to lowercase, or
preserved as is. `-fsource-case-lower' is the default.
`-fsymbol-case-initcap'
`-fsymbol-case-upper'
`-fsymbol-case-lower'
`-fsymbol-case-any'
Specify valid cases for user-defined symbol names.
`-fsymbol-case-any' is the default.
`-fcase-strict-upper'
Same as `-fintrin-case-upper -fmatch-case-upper
-fsource-case-preserve -fsymbol-case-upper'. (Requires all
pertinent source to be in uppercase.)
`-fcase-strict-lower'
Same as `-fintrin-case-lower -fmatch-case-lower
-fsource-case-preserve -fsymbol-case-lower'. (Requires all
pertinent source to be in lowercase.)
`-fcase-initcap'
Same as `-fintrin-case-initcap -fmatch-case-initcap
-fsource-case-preserve -fsymbol-case-initcap'. (Requires all
pertinent source to be in initial capitals, as in `Print
*,SqRt(Value)'.)
`-fcase-upper'
Same as `-fintrin-case-any -fmatch-case-any -fsource-case-upper
-fsymbol-case-any'. (Maps all pertinent source to uppercase.)
`-fcase-lower'
Same as `-fintrin-case-any -fmatch-case-any -fsource-case-lower
-fsymbol-case-any'. (Maps all pertinent source to lowercase.)
`-fcase-preserve'
Same as `-fintrin-case-any -fmatch-case-any -fsource-case-preserve
-fsymbol-case-any'. (Preserves all case in user-defined symbols,
while allowing any-case matching of intrinsics and keywords. For
example, `call Foo(i,I)' would pass two *different* variables
named `i' and `I' to a procedure named `Foo'.)
`-fdcp-intrinsics-delete'
`-fdcp-intrinsics-hide'
`-fdcp-intrinsics-disable'
`-fdcp-intrinsics-enable'
Specify status of Digital's COMPLEX-related intrinsics.
`-fdcp-intrinsics-enable' is the default.
`-ff2c-intrinsics-delete'
`-ff2c-intrinsics-hide'
`-ff2c-intrinsics-disable'
`-ff2c-intrinsics-enable'
Specify status of f2c-specific intrinsics.
`-ff2c-intrinsics-enable' is the default.
`-ff90-intrinsics-delete'
`-ff90-intrinsics-hide'
`-ff90-intrinsics-disable'
`-ff90-intrinsics-enable'
Specify status of F90-specific intrinsics.
`-ff90-intrinsics-delete' is the default.
`-fmil-intrinsics-delete'
`-fmil-intrinsics-hide'
`-fmil-intrinsics-disable'
`-fmil-intrinsics-enable'
Specify status of MIL-STD-1753-specific intrinsics.
`-fmil-intrinsics-enable' is the default.
`-funix-intrinsics-delete'
`-funix-intrinsics-hide'
`-funix-intrinsics-disable'
`-funix-intrinsics-enable'
Specify status of UNIX intrinsics. `-funix-intrinsics-enable' is
the default.
For example, if your code invokes `FLUSH' as a library function
and thus works with other UNIX Fortran compilers or earlier
version of `g77', either add the `EXTERNAL FLUSH' statement or,
perhaps more convenient for you, compile with the
-funix-intrinsics-hide or -funix-intrinsics-delete option.
Note that `ABORT', `EXIT', `FLUSH', `SIGNAL', and `SYSTEM' are
intrinsic subroutines, not functions (since they have side
effects), so to get the return values from `SIGNAL' and `SYSTEM',
append a final argument specifying an `INTEGER' variable or array
element to receive the returned status. (For example, `CALL
SYSTEM('rm foo',ISTAT)'.)
`FLUSH()' accepts an optional single `INTEGER' argument, since
many Fortran implementations allow or require a unit number.
Currently, since `libf2c' does not flush a given unit number, this
argument is not used--all units are flushed by `libf2c''s
implementation of `FLUSH()'. Do not depend on this behavior--if
you want to flush all units, use `CALL FLUSH' (that is, specify no
arguments to `FLUSH').
`EXIT()' accepts an optional single `INTEGER' argument. If
omitted, zero is the default (as in `CALL EXIT(0)'). The default
might change on configurations where the "normal return status" is
not zero, however. If you want to return a "success" status, it
is best to call `EXIT' with no arguments in your code, and let
`g77' choose the appropriate default.
`-fvxt-intrinsics-delete'
`-fvxt-intrinsics-hide'
`-fvxt-intrinsics-disable'
`-fvxt-intrinsics-enable'
Specify status of VXT intrinsics. `-fvxt-intrinsics-delete' is
the default.
`-ffixed-line-length-N'
Set column after which characters are ignored in typical fixed-form
lines in the source file.
Popular values for N include 72 (the standard and the default), 80
(card image), and 132 (corresponds to "extended-source" options in
some popular compilers). N may be `none', meaning that the entire
line is meaningful and that continued character constants never
have implicit spaces appended to them to fill out the line.
`-ffixed-line-length-0' means the same thing as
`-ffixed-line-length-none'.
File: ^.!gcc.docs.fortran.g77, Node: Warning Options, Next: Debugging Options, Prev: Fortran Dialect Options, Up: Invoking G77
Options to Request or Suppress Warnings
=======================================
Warnings are diagnostic messages that report constructions which are
not inherently erroneous but which are risky or suggest there might
have been an error.
You can request many specific warnings with options beginning `-W',
for example `-Wimplicit' to request warnings on implicit declarations.
Each of these specific warning options also has a negative form
beginning `-Wno-' to turn off warnings; for example, `-Wno-implicit'.
This manual lists only one of the two forms, whichever is not the
default.
These options control the amount and kinds of warnings produced by
GNU Fortran:
`-fsyntax-only'
Check the code for syntax errors, but don't do anything beyond
that.
`-pedantic'
Issue warnings for uses of extensions to ANSI FORTRAN 77.
`-pedantic' also applies to C-language constructs where they occur
in GNU Fortran source files, such as use of `\e' in a character
constant within a directive like `#include'.
Valid ANSI FORTRAN 77 programs should compile properly with or
without this option. However, without this option, certain GNU
extensions and traditional Fortran features are supported as well.
With this option, many of them are rejected.
Some users try to use `-pedantic' to check programs for strict ANSI
conformance. They soon find that it does not do quite what they
want: it finds some non-ANSI practices, but not all--however,
improvements to `g77' in this area are welcome.
`-pedantic-errors'
Like `-pedantic', except that errors are produced rather than
warnings.
`-fpedantic'
Like `-pedantic', but applies only to Fortran constructs.
`-fugly'
Specify that certain "ugly" constructs are to be quietly accepted.
Implies `-fugly-args' and `-fugly-init' as well.
For example, with `-fno-ugly', `CALL FOO(,)' means to pass one
null argument, whereas with `-fugly', it means to pass two null
arguments.
`-fno-ugly-args'
Disallow passing Hollerith and typeless constants as actual
arguments (for example, `CALL FOO(4HABCD)').
`-fno-ugly-init'
Disallow use of Hollerith and typeless constants as initial values
(in `PARAMETER' and `DATA' statements), and use of character
constants to initialize numeric types and vice versa.
For example, `DATA I/'F'/, CHRVAR/65/, J/4HABCD/' is disallowed by
`-fno-ugly-init'.
Inhibit all warning messages.
`-Wimplicit'
Warn whenever a variable, array, or function is implicitly
declared. Has an effect similar to using the `IMPLICIT NONE'
statement in every program unit. (Some Fortran compilers provide
this feature by an option named `-u' or `/WARNINGS=DECLARATIONS'.)
`-Wunused'
Warn whenever a variable is unused aside from its declaration.
`-Wuninitialized'
Warn whenever an automatic variable is used without first being
initialized.
These warnings are possible only in optimizing compilation,
because they require data flow information that is computed only
when optimizing. If you don't specify `-O', you simply won't get
these warnings.
These warnings occur only for variables that are candidates for
register allocation. Therefore, they do not occur for a variable
that is declared `volatile', or whose address is taken, or whose
size is other than 1, 2, 4 or 8 bytes. Also, they do not occur for
arrays, even when they are in registers.
Note that there may be no warning about a variable that is used
only to compute a value that itself is never used, because such
computations may be deleted by data flow analysis before the
warnings are printed.
These warnings are made optional because GNU Fortran is not smart
enough to see all the reasons why the code might be correct
despite appearing to have an error. Here is one example of how
this can happen:
SUBROUTINE DISPAT(J)
IF (J.EQ.1) I=1
IF (J.EQ.2) I=4
IF (J.EQ.3) I=5
CALL FOO(I)
END
If the value of `J' is always 1, 2 or 3, then `I' is always
initialized, but GNU Fortran doesn't know this. Here is another
common case:
SUBROUTINE MAYBE(FLAG)
LOGICAL FLAG
IF (FLAG) VALUE = 3.14
...
IF (FLAG) PRINT *, VALUE
END
This has no bug because `VALUE' is used only if it is set.
`-Wall'
The `-Wunused' and `-Wuninitialized' options combined. These are
all the options which pertain to usage that we recommend avoiding
and that we believe is easy to avoid. (As more warnings are added
to `g77', some might be added to the list enabled by `-Wall'.)
The remaining `-W...' options are not implied by `-Wall' because
they warn about constructions that we consider reasonable to use, on
occasion, in clean programs.
`-Wsurprising'
Warn about "suspicious" constructs that are interpreted by the
compiler in a way that might well be surprising to someone reading
the code. These differences can result in subtle,
compiler-dependent (even machine-dependent) behavioral differences.
The constructs warned about include:
* Expressions having two arithmetic operators in a row, such as
`X*-Y'. Such a construct is nonstandard, and can produce
unexpected results in more complicated situations such as
`X**-Y*Z'. `g77', along with many other compilers, interprets
this example differently than many programmers, and a few
other compilers. Specifically, `g77' interprets `X**-Y*Z' as
`(X**(-Y))*Z', while others might think it should be
interpreted as `X**(-(Y*Z))'.
A revealing example is the constant expression `2**-2*1.',
which `g77' evaluates to .25, while others might evaluate it
to 0., the difference being the way precedence affects type
promotion.
(The `-fpedantic' option also warns about expressions having
two arithmetic operators in a row.)
* Expressions with a unary minus followed by an operand and then
a binary operator other than plus or minus. For example,
`-2**2' produces a warning, because the precedence is
`-(2**2)', yielding -4, not `(-2)**2', which yields 4, and
which might represent what a programmer expects. Even cases
such as `-I*J' produce warnings, even though, in most
configurations and situations, there is no computational
difference between the results of the two
interpretations--the purpose of this warning is to warn about
differing interpretations and encourage a better style of
coding, not to identify only those places where bugs might
exist in the user's code.
* `DO' loops with `DO' variables that are not of integral
type--that is, using `REAL' or `DOUBLE PRECISION' variables
as loop control variables. Although such loops can be
written to work in the "obvious" way, the way `g77' is
required by the Fortran standard to interpret such code is
likely to be quite different from the way many programmers
expect. (This is true of all `DO' loops, but the differences
are pronounced for non-integral loop control variables.)
*Note Loops::, for more information.
`-Werror'
Make all warnings into errors.
Turns on "extra warnings" and the `uninitialized' option. (This
might change in future versions of `g77'.)
"Extra warnings" are issued for:
* Unused parameters to a procedure (when `-Wunused' also is
specified).
* Overflows involving floating-point constants (not available
for certain configurations?).
*Note Options to Request or Suppress Warnings: (gcc)Warning Options,
for information on more options offered by the GBE shared by `g77',
`gcc', and other GNU compilers.
Some of these have no effect when compiling programs written in
Fortran:
`-Wcomment'
`-Wformat'
`-Wparentheses'
`-Wswitch'
`-Wtraditional'
`-Wshadow'
`-Wid-clash-LEN'
`-Wlarger-than-LEN'
`-Wconversion'
`-Waggregate-return'
`-Wredundant-decls'
These options all could have some relevant meaning for GNU Fortran
programs, but are not yet supported.
File: ^.!gcc.docs.fortran.g77, Node: Debugging Options, Next: Optimize Options, Prev: Warning Options, Up: Invoking G77
Options for Debugging Your Program or GNU Fortran
=================================================
GNU Fortran has various special options that are used for debugging
either your program or `g77'.
Produce debugging information in the operating system's native
format (stabs, COFF, XCOFF, or DWARF). GDB can work with this
debugging information.
Support for this option in Fortran programs is incomplete. In
particular, names of variables and arrays in common blocks or that
are storage-associated via `EQUIVALENCE' are unavailable to the
debugger.
*Note Options for Debugging Your Program or GNU CC: (gcc)Debugging
Options, for more information on debugging options.
File: ^.!gcc.docs.fortran.g77, Node: Optimize Options, Next: Preprocessor Options, Prev: Debugging Options, Up: Invoking G77
Options That Control Optimization
=================================
Most Fortran users will want to use no optimization when developing
and testing programs, and use `-O' or `-O2' when compiling programs for
late-cycle testing and for production use.
The following flags have particular applicability when compiling
Fortran programs:
`-ffloat-store'
Might help a Fortran program that depends on exact IEEE conformance
on some machines, but might slow down a program that doesn't.
`-fforce-mem'
`-fforce-addr'
Might improve optimization of loops.
`-fno-inline'
Don't compile statement functions inline. Might reduce the size
of a program unit--which might be at expense of some speed (though
it should compile faster). Note that if you are not optimizing,
no functions can be expanded inline.
`-ffast-math'
Might allow some programs designed to not be too dependent on IEEE
behavior for floating-point to run faster, or die trying.
`-fstrength-reduce'
Might make some loops run faster.
`-frerun-cse-after-loop'
`-fexpensive-optimizations'
`-fdelayed-branch'
`-fschedule-insns'
`-fschedule-insns2'
`-fcaller-saves'
Might improve performance on some code.
`-funroll-loops'
Definitely improves performance on some code.
`-funroll-all-loops'
Definitely improves performance on some code.
`-fno-move-all-movables'
`-fno-reduce-all-givs'
`-fno-rerun-loop-opt'
Each of these might improve performance on some code.
Analysis of Fortran code optimization and the resulting
optimizations triggered by the above options were contributed by
Toon Moene (`toon@moene.indiv.nluug.nl').
Please let us know how use of these options affects the
performance of your production code. We're particularly
interested in code that runs faster when these options are
*disabled*, and in non-Fortran code that benefits when they are
*enabled* via the above `gcc' command-line options.
*Note Options That Control Optimization: (gcc)Optimize Options, for
more information on options to optimize the generated machine code.
File: ^.!gcc.docs.fortran.g77, Node: Preprocessor Options, Next: Directory Options, Prev: Optimize Options, Up: Invoking G77
Options Controlling the Preprocessor
====================================
These options control the C preprocessor, which is run on each C
source file before actual compilation.
*Note Options Controlling the Preprocessor: (gcc)Preprocessor
Options, for information on C preprocessor options.
Some of these options also affect how `g77' processes the `INCLUDE'
statement. Since this statement is processed even when preprocessing
is not requested, it is not described in this section. *Note Options
for Directory Search: Directory Options, for information on how `g77'
processes the `INCLUDE' statement.
File: ^.!gcc.docs.fortran.g77, Node: Directory Options, Next: Code Gen Options, Prev: Preprocessor Options, Up: Invoking G77
Options for Directory Search
============================
These options affect how the `cpp' preprocessor searches for files
specified via the `#include' directive. Therefore, when compiling
Fortran programs, they are meaningful when the preproecssor is used.
Some of these options also affect how `g77' searches for files
specified via the `INCLUDE' statement. These options are:
`-I-'
`-IDIR'
These affect interpretation of the `INCLUDE' statement (as well as
of the `#include' directive of the `cpp' preprocessor).
Note that `-IDIR' must be specified *without* any spaces between
`-I' and the directory name--that is, `-Ifoo/bar' is valid, but
`-I foo/bar' is rejected by the `g77' compiler (though the
preprocessor supports the latter form). Also note that the
general behavior of `-I' and `INCLUDE' is pretty much the same as
of `-I' with `#include' in the `cpp' preprocessor, with regard to
looking for `header.gcc' files and other such things.
*Note Options for Directory Search: (gcc)Directory Optoins, for
information on the `-I' option.
File: ^.!gcc.docs.fortran.g77, Node: Code Gen Options, Next: Environment Variables, Prev: Directory Options, Up: Invoking G77
Options for Code Generation Conventions
=======================================
These machine-independent options control the interface conventions
used in code generation.
Most of them have both positive and negative forms; the negative form
of `-ffoo' would be `-fno-foo'. In the table below, only one of the
forms is listed--the one which is not the default. You can figure out
the other form by either removing `no-' or adding it.
`-fno-automatic'
Treat each program unit as if the `SAVE' statement was specified
for every local variable and array referenced in it. Does not
affect common blocks. (Some Fortran compilers provide this option
under the name `-static'.)
`-finit-local-zero'
Specify that variables and arrays that are local to a program unit
(not in a common block and not passed as an argument) are to be
initialized to binary zeros.
Since there is a run-time penalty for initialization of variables
that are not given the `SAVE' attribute, it might be a good idea
to also use `-fno-automatic' with `-finit-local-zero'.
`-fno-f2c'
Do not generate code designed to be compatible with code generated
by `f2c'.
This does not affect the generation of code that interfaces with
the `libf2c' library.
*Caution:* If `-fno-f2c' is used when compiling any source file
used in a program, it must be used when compiling *all* Fortran
source files used in that program.
`-ff2c-library'
Specify that use of `libf2c' is required. This is the default for
the current version of `g77'.
Currently it is not valid to specify `-fno-f2c-library'. This
option is provided so users can specify it in shell scripts that
build programs and libraries that require the `libf2c' library,
even when being compiled by future versions of `g77' that might
otherwise default to generating code for an incompatible library.
`-fno-underscoring'
Do not transform names of entities specified in the Fortran source
file by appending underscores to them.
With `-funderscoring' in effect, `g77' appends two underscores to
names with underscores and one underscore to external names with
no underscores. (`g77' also appends two underscores to internal
names with underscores to avoid naming collisions with external
names.)
This is done to ensure compatibility with code produced by many
UNIX Fortran compilers, including `f2c', which perform the same
transformations.
Use of `-fno-underscoring' is not recommended unless you are
experimenting with issues such as integration of (GNU) Fortran into
existing system environments (vis-a-vis existing libraries, tools,
and so on).
For example, with `-funderscoring', and assuming other defaults
like `-fcase-lower' and that `j()' and `max_count()' are external
functions while `my_var' and `lvar' are local variables, a
statement like
I = J() + MAX_COUNT (MY_VAR, LVAR)
is implemented as something akin to:
i = j_() + max_count__(&my_var__, &lvar);
With `-fno-underscoring', the same statement is implemented as:
i = j() + max_count(&my_var, &lvar);
Use of `-fno-underscoring' allows direct specification of
user-defined names while debugging and when interfacing
`g77'-compiled code with other languages.
Note that just because the names match does *not* mean that the
interface implemented by `g77' for an external name matches the
interface implemented by some other language for that same name.
That is, getting code produced by `g77' to link to code produced
by some other compiler using this or any other method can be only a
small part of the overall solution--getting the code generated by
both compilers to agree on issues other than naming can require
significant effort, and, unlike naming disagreements, linkers
normally cannot detect disagreements in these other areas.
Also, note that with `-fno-underscoring', the lack of appended
underscores introduces the very real possibility that a
user-defined external name will conflict with a name in a system
library, which could make finding unresolved-reference bugs quite
difficult in some cases--they might occur at program run time, and
show up only as buggy behavior at run time.
In future versions of `g77', we hope to improve naming and linking
issues so that debugging always involves using the names as they
appear in the source, even if the names as seen by the linker are
mangled to prevent accidental linking between procedures with
incompatible interfaces.
`-fno-second-underscore'
Do not append a second underscore to names of entities specified
in the Fortran source file.
This option has no effect if `-fno-underscoring' is not in effect.
Otherwise, with this option, an external name such as `MAX_COUNT'
is implemented as a reference to the link-time external symbol
`max_count_', instead of `max_count__'.
`-fno-ident'
Ignore the `#ident' directive.
`-fzeros'
Treat initial values of zero as if they were any other value.
As of version 0.5.18, `g77' normally treats `DATA' and other
statements that are used specify initial values of zero for
variables and arrays as if no values were actually specified, in
the sense that no diagnostics regarding multiple initializations
are produced.
This is done to speed up compiling of programs that initialize
large arrays to zeros.
Use `-fzeros' to revert to the simpler, slower behavior that can
catch multiple initializations by keeping track of all
initializations, zero or otherwise.
*Caution:* Future versions of `g77' might disregard this option
(and its negative form, the default) or interpret it somewhat
differently. The interpretation changes will affect only
non-standard programs; standard-conforming programs should not be
affected.
*Note Options for Code Generation Conventions: (gcc)Code Gen
Options, for information on more options offered by the GBE shared by
`g77', `gcc', and other GNU compilers.
Some of these do *not* work when compiling programs written in
Fortran:
`-fpcc-struct-return'
`-freg-struct-return'
You should not use these except strictly the same way as you used
them to build the version of `libf2c' with which you will be
linking all code compiled by `g77' with the same option.
`-fshort-double'
This probably either has no effect on Fortran programs, or makes
them act loopy.
`-fno-common'
Do not use this when compiling Fortran programs, or there will be
Trouble.
`-fpack-struct'
This probably will break any calls to the `libf2c' library, at the
very least, even if it is built with the same option.
File: ^.!gcc.docs.fortran.g77, Node: Environment Variables, Prev: Code Gen Options, Up: Invoking G77
Environment Variables Affecting GNU Fortran
===========================================
GNU Fortran currently does not make use of any environment variables
to control its operation above and beyond those that affect the
operation of `gcc'.
*Note Environment Variables Affecting GNU CC: (gcc)Environment
Variables, for information on environment variables.
File: ^.!gcc.docs.fortran.g77, Node: News, Next: Changes, Prev: Invoking G77, Up: Top
News About GNU Fortran
**********************
In 0.5.18:
==========
* Add some rudimentary support for `INTEGER*1', `INTEGER*2',
`INTEGER*8', and their `LOGICAL' equivalents. (This support works
on most, maybe all, `gcc' targets.)
Thanks to Scott Snyder (`snyder@d0sgif.fnal.gov') for providing
the patch for this!
Among the missing elements from the support for these features are
full intrinsic support and constants.
* Add some rudimentary support for the `BYTE' and `WORD'
type-declaration statements. `BYTE' corresponds to `INTEGER*1',
while `WORD' corresponds to `INTEGER*2'.
Thanks to Scott Snyder (`snyder@d0sgif.fnal.gov') for providing
the patch for this!
* The compiler code handling intrinsics has been largely rewritten
to accommodate the new types. No new intrinsics or arguments for
existing intrinsics have been added, so there is, at this point,
no intrinsic to convert to `INTEGER*8', for example.
* Support automatic arrays in procedures.
* Reduce space/time requirements for handling large *sparsely*
initialized aggregate arrays. This improvement applies to only a
subset of the general problem to be addressed in 0.6.
* Treat initial values of zero as if they weren't specified (in DATA
and type-declaration statements). The initial values will be set
to zero anyway, but the amount of compile time processing them
will be reduced, in some cases significantly (though, again, this
is only a subset of the general problem to be addressed in 0.6).
A new option, `-fzeros', is introduced to enable the traditional
treatment of zeros as any other value.
* With `-ff90' in force, `g77' incorrectly interpreted `REAL(Z)' as
returning a `REAL' result, instead of as a `DOUBLE PRECISION'
result. (Here, `Z' is `DOUBLE COMPLEX'.)
With `-fno-f90' in force, the interpretation remains unchanged,
since this appears to be how at least some F77 code using the
`DOUBLE COMPLEX' extension expected it to work.
Essentially, `REAL(Z)' in F90 is the same as `DBLE(Z)', while in
extended F77, it appears to be the same as `REAL(REAL(Z))'.
* An expression involving exponentiation, where both operands were
type `INTEGER' and the right-hand operand was negative, was
erroneously evaluated.
* Fix bugs involving `DATA' implied-`DO' constructs (these involved
an errant diagnostic and a crash, both on good code, one involving
subsequent statement-function definition).
* Close `INCLUDE' files after processing them, so compiling source
files with lots of `INCLUDE' statements does not result in being
unable to open `INCLUDE' files after all the available file
descriptors are used up.
* Speed up compiling, especially of larger programs, and perhaps
slightly reduce memory utilization while compiling (this is *not*
the improvement planned for 0.6 involving large aggregate
areas)--these improvements result from simply turning off some
low-level code to do self-checking that hasn't been triggered in a
long time.
* Introduce three new options that implement optimizations in the
`gcc' back end (GBE). These options are `-fmove-all-movables',
`-freduce-all-givs', and `-frerun-loop-opt', which are enabled, by
default, for Fortran compilations. These optimizations are
intended to help toon Fortran programs.
* Patch the GBE to do a better job optimizing certain kinds of
references to array elements.
* Due to patches to the GBE, the version number of `gcc' also is
patched to make it easier to manage installations, especially
useful if it turns out a `g77' change to the GBE has a bug.
The `g77'-modified version number is the `gcc' version number with
the string `.f.N' appended, where `f' identifies the version as
enhanced for Fortran, and N is `1' for the first Fortran patch for
that version of `gcc', `2' for the second, and so on.
So, this introduces version `2.7.2.f.1' of `gcc'.
* Make several improvements and fixes to diagnostics, including the
removal of two that were inappropriate or inadequate.
* Warning about two successive arithmetic operators, produced by
`-Wsurprising', now produced *only* when both operators are,
indeed, arithmetic (not relational/boolean).
* `-Wsurprising' now warns about the remaining cases of using
non-integral variables for implied-`DO' loops, instead of these
being rejected unless `-fpedantic' or `-fugly' specified.
* Allow `SAVE' of a local variable or array, even after it has been
given an initial value via `DATA', for example.
* Introduce an Info version of `g77' documentation, which supercedes
`gcc/f/CREDITS', `gcc/f/DOC', and `gcc/f/PROJECTS'. These files
will be removed in a future release. The files `gcc/f/BUGS',
`gcc/f/INSTALL', and `gcc/f/NEWS' now are automatically built from
the texinfo source when distributions are made.
This effort was inspired by a first pass at translating
`g77-0.5.16/f/DOC' that was contributed to Craig by David Ronis
(`ronis@onsager.chem.mcgill.ca').
* New `-fno-second-underscore' option to specify that, when
`-funderscoring' is in effect, a second underscore is not to be
appended to Fortran names already containing an underscore.
* Change the way iterative `DO' loops work to follow the F90
standard. In particular, calculation of the iteration count is
still done by converting the start, end, and increment parameters
to the type of the `DO' variable, but the result of the
calculation is always converted to the default `INTEGER' type.
(This should have no effect on existing code compiled by `g77',
but code written to assume that use of a *wider* type for the `DO'
variable will result in an iteration count being fully calculated
using that wider type (wider than default `INTEGER') must be
rewritten.)
* Upgrade to `libf2c' as of 1996-03-23, and fix up some of the build
procedures.
Note that the email addresses related to `f2c' have changed--the
distribution site now is named `netlib.bell-labs.com', and the
maintainer's new address is `dmg@bell-labs.com'.
In 0.5.17:
==========
* *Fix serious bug* in `g77 -v' command that can cause removal of a
system's `/dev/null' special file if run by user `root'.
*All users* of version 0.5.16 should ensure that they have not
removed `/dev/null' or replaced it with an ordinary file (e.g. by
comparing the output of `ls -l /dev/null' with `ls -l /dev/zero'.
If the output isn't basically the same, contact your system
administrator about restoring `/dev/null' to its proper status).
This bug is particularly insidious because removing `/dev/null' as
a special file can go undetected for quite a while, aside from
various applications and programs exhibiting sudden, strange
behaviors.
I sincerely apologize for not realizing the implications of the
fact that when `g77 -v' runs the `ld' command with `-o /dev/null'
that `ld' tries to *remove* the executable it is supposed to build
(especially if it reports unresolved references, which it should
in this case)!
* Fix crash on `CHARACTER*(*) FOO' in a main or block data program
unit.
* Fix crash that can occur when diagnostics given outside of any
program unit (such as when input file contains `@foo').
* Fix crashes, infinite loops (hangs), and such involving diagnosed
code.
* Fix `ASSIGN''ed variables so they can be `SAVE''d or dummy
arguments, and issue clearer error message in cases where target
of `ASSIGN' or `ASSIGN'ed `GOTO'/`FORMAT' is too small (which
should never happen).
* Make `libf2c' build procedures work on more systems again by
eliminating unnecessary invocations of `ld -r -x' and `mv'.
* Fix omission of `-funix-intrinsics-...' options in list of
permitted options to compiler.
* Fix failure to always diagnose missing type declaration for
`IMPLICIT NONE'.
* Fix compile-time performance problem (which could sometimes crash
the compiler, cause a hang, or whatever, due to a bug in the back
end) involving exponentiation with a large `INTEGER' constant for
the right-hand operator (e.g. `I**32767').
* Fix build procedures so cross-compiling `g77' (the `fini' utility
in particular) is properly built using the host compiler.
* Add new `-Wsurprising' option to warn about constructs that are
interpreted by the Fortran standard (and `g77') in ways that are
surprising to many programmers.
* Add `ERF()' and `ERFC()' as generic intrinsics mapping to existing
`ERF'/`DERF' and `ERFC'/`DERFC' specific intrinsics.
*Note:* You should specify `INTRINSIC ERF,ERFC' in any code where
you might use these as generic intrinsics, to improve likelihood
of diagnostics (instead of subtle run-time bugs) when using a
compiler that doesn't support these as intrinsics (e.g. `f2c').
* Remove from `-fno-pedantic' the diagnostic about `DO' with
non-`INTEGER' index variable; issue that under `-Wsurprising'
instead.
* Clarify some diagnostics that say things like "ignored" when that's
misleading.
* Clarify diagnostic on use of `.EQ.'/`.NE.' on `LOGICAL' operands.
* Minor improvements to code generation for various operations on
`LOGICAL' operands.
* Minor improvement to code generation for some `DO' loops on some
machines.
* Support `gcc' version 2.7.1.
* Upgrade to `libf2c' as of 1995-11-15.
In 0.5.16:
==========
* Fix a code-generation bug involving complicated `EQUIVALENCE'
statements not involving `COMMON'
* Fix code-generation bugs involving invoking "gratis" library
procedures in `libf2c' from code compiled with `-fno-f2c' by
making these procedures known to `g77' as intrinsics (not affected
by -fno-f2c). This is known to fix code invoking `ERF()',
`ERFC()', `DERF()', and `DERFC()'.
* Update `libf2c' to include netlib patches through 1995-08-16, and
`#define' `WANT_LEAD_0' to 1 to make `g77'-compiled code more
consistent with other Fortran implementations by outputting
leading zeros in formatted and list-directed output.
* Fix a code-generation bug involving adjustable dummy arrays with
high bounds whose primaries are changed during procedure
execution, and which might well improve code-generation
performance for such arrays compared to `f2c' plus `gcc' (but
apparently only when using `gcc-2.7.0' or later).
* Fix a code-generation bug involving invocation of `COMPLEX' and
`DOUBLE COMPLEX' `FUNCTION's and doing `COMPLEX' and `DOUBLE
COMPLEX' divides, when the result of the invocation or divide is
assigned directly to a variable that overlaps one or more of the
arguments to the invocation or divide.
* Fix crash by not generating new optimal code for `X**I' if `I' is
nonconstant and the expression is used to dimension a dummy array,
since the `gcc' back end does not support the necessary mechanics
(and the `gcc' front end rejects the equivalent construct, as it
turns out).
* Fix crash on expressions like `COMPLEX**INTEGER'.
* Fix crash on expressions like `(1D0,2D0)**2', i.e. raising a
`DOUBLE COMPLEX' constant to an `INTEGER' constant power.
* Fix crashes and such involving diagnosed code.
* Diagnose, instead of crashing on, statement function definitions
having duplicate dummy argument names.
* Fix bug causing rejection of good code involving statement function
definitions.
* Fix bug resulting in debugger not knowing size of local equivalence
area when any member of area has initial value (via `DATA', for
example).
* Fix installation bug that prevented installation of `g77' driver.
Provide for easy selection of whether to install copy of `g77' as
`f77' to replace the broken code.
* Fix `gcc' driver (affects `g77' thereby) to not gratuitously
invoke the `f771' program (e.g. when `-E' is specified).
* Fix diagnostic to point to correct source line when it immediately
follows an `INCLUDE' statement.
* Support more compiler options in `gcc'/`g77' when compiling
Fortran files. These options include `-p', `-pg', `-aux-info',
`-P', correct setting of version-number macros for preprocessing,
full recognition of `-O0', and automatic insertion of
configuration-specific linker specs.
* Add new intrinsics that interface to existing routines in `libf2c':
`ABORT', `DERF', `DERFC', `ERF', `ERFC', `EXIT', `FLUSH',
`GETARG', `GETENV', `IARGC', `SIGNAL', and `SYSTEM'. Note that
`ABORT', `EXIT', `FLUSH', `SIGNAL', and `SYSTEM' are intrinsic
subroutines, not functions (since they have side effects), so to
get the return values from `SIGNAL' and `SYSTEM', append a final
argument specifying an `INTEGER' variable or array element (e.g.
`CALL SYSTEM('rm foo',ISTAT)').
* Add new intrinsic group named `unix' to contain the new intrinsics,
and by default enable this new group.
* Move `LOC()' intrinsic out of the `vxt' group to the new `unix'
group.
* Improve `g77' so that `g77 -v' by itself (or with certain other
options, including `-B', `-b', `-i', `-nostdlib', and `-V')
reports lots more useful version info, and so that long-form
options `gcc' accepts are understood by `g77' as well (even in
truncated, unambiguous forms).
* Add new `g77' option `--driver=name' to specify driver when
default, `gcc', isn't appropriate.
* Add support for `#' directives (as output by the preprocessor) in
the compiler, and enable generation of those directives by the
preprocessor (when compiling `.F' files) so diagnostics and
debugging info are more useful to users of the preprocessor.
* Produce better diagnostics, more like `gcc', with info such as `In
function `foo':' and `In file included from...:'.
* Support `gcc''s `-fident' and `-fno-ident' options.
* When `-Wunused' in effect, don't warn about local variables used as
statement-function dummy arguments or `DATA' implied-`DO' iteration
variables, even though, strictly speaking, these are not uses of
the variables themselves.
* When `-W -Wunused' in effect, don't warn about unused dummy
arguments at all, since there's no way to turn this off for
individual cases (`g77' might someday start warning about
these)--applies to `gcc' versions 2.7.0 and later, since earlier
versions didn't warn about unused dummy arguments.
* New option `-fno-underscoring' that inhibits transformation of
names (by appending one or two underscores) so users may experiment
with implications of such an environment.
* Minor improvement to `gcc/f/info' module to make it easier to build
`g77' using the native (non-`gcc') compiler on certain machines
(but definitely not all machines nor all non-`gcc' compilers).
Please do not report bugs showing problems compilers have with
macros defined in `gcc/f/target.h' and used in places like
`gcc/f/expr.c'.
* Add warning to be printed for each invocation of the compiler if
the target machine `INTEGER', REAL, or `LOGICAL' size is not 32
bits, since `g77' is known to not work well for such cases (to be
fixed in Version 0.6--*note Actual Bugs We Haven't Fixed Yet:
Actual Bugs.).
* Lots of new documentation (though work is still needed to put it
into canonical GNU format).
* Build `libf2c' with `-g0', not `-g2', in effect (by default), to
produce smaller library without lots of debugging clutter.
In 0.5.15:
==========
* Fix bad code generation involving `X**I' and temporary, internal
variables generated by `g77' and the back end (such as for `DO'
loops).
* Fix crash given `CHARACTER A;DATA A/.TRUE./'.
* Replace crash with diagnostic given `CHARACTER A;DATA A/1.0/'.
* Fix crash or other erratic behavior when null character constant
(`''') is encountered.
* Fix crash or other erratic behavior involving diagnosed code.
* Fix code generation for external functions returning type `REAL'
when the `-ff2c' option is in force (which it is by default) so
that `f2c' compatibility is indeed provided.
* Disallow `COMMON I(10)' if `I' has previously been specified with
an array declarator.
* New `-ffixed-line-length-N' option, where N is the maximum length
of a typical fixed-form line, defaulting to 72 columns, such that
characters beyond column N are ignored, or N is `none', meaning no
characters are ignored. does not affect lines with `&' in column
1, which are always processed as if `-ffixed-line-length-none' was
in effect.
* No longer generate better code for some kinds of array references,
as `gcc' back end is to be fixed to do this even better, and it
turned out to slow down some code in some cases after all.
* In `COMMON' and `EQUIVALENCE' areas with any members given initial
values (e.g. via `DATA'), uninitialized members now always
initialized to binary zeros (though this is not required by the
standard, and might not be done in future versions of `g77').
Previously, in some `COMMON'/`EQUIVALENCE' areas (essentially
those with members of more than one type), the uninitialized
members were initialized to spaces, to cater to `CHARACTER' types,
but it seems no existing code expects that, while much existing
code expects binary zeros.
In 0.5.14:
==========
* Don't emit bad code when low bound of adjustable array is
nonconstant and thus might vary as an expression at run time.
* Emit correct code for calculation of number of trips in `DO' loops
for cases where the loop should not execute at all. (This bug
affected cases where the difference between the begin and end
values was less than the step count, though probably not for
floating-point cases.)
* Fix crash when extra parentheses surround item in `DATA'
implied-`DO' list.
* Fix crash over minor internal inconsistencies in handling
diagnostics, just substitute dummy strings where necessary.
* Fix crash on some systems when compiling call to `MVBITS()'
intrinsic.
* Fix crash on array assignment `TYPEDDD(...)=...', where DDD is a
string of one or more digits.
* Fix crash on `DCMPLX()' with a single `INTEGER' argument.
* Fix various crashes involving code with diagnosed errors.
* Support `-I' option for `INCLUDE' statement, plus `gcc''s
`header.gcc' facility for handling systems like MS-DOS.
* Allow `INCLUDE' statement to be continued across multiple lines,
even allow it to coexist with other statements on the same line.
* Incorporate Bellcore fixes to `libf2c' through 1995-03-15--this
fixes a bug involving infinite loops reading EOF with empty
list-directed I/O list.
* Remove all the `g77'-specific auto-configuration scripts, code,
and so on, except for temporary substitutes for bsearch() and
strtoul(), as too many configure/build problems were reported in
these areas. People will have to fix their systems' problems
themselves, or at least somewhere other than `g77', which expects
a working ANSI C environment (and, for now, a GNU C compiler to
compile `g77' itself).
* Complain if initialized common redeclared as larger in subsequent
program unit.
* Warn if blank common initialized, since its size can vary and hence
related warnings that might be helpful won't be seen.
* New `-fbackslash' option, on by default, that causes `\' within
`CHARACTER' and Hollerith constants to be interpreted a la GNU C.
Note that this behavior is somewhat different from `f2c''s, which
supports only a limited subset of backslash (escape) sequences.
* Make `-fugly-args' the default.
* New `-fugly-init' option, on by default, that allows
typeless/Hollerith to be specified as initial values for variables
or named constants (`PARAMETER'), and also allows
character<->numeric conversion in those contexts--turn off via
`-fno-ugly-init'.
* New `-finit-local-zero' option to initialize local variables to
binary zeros. This does not affect whether they are `SAVE'd, i.e.
made automatic or static.
* New `-Wimplicit' option to warn about implicitly typed variables,
arrays, and functions. (Basically causes all program units to
default to `IMPLICIT NONE'.)
* `-Wall' now implies `-Wuninitialized' as with `gcc' (i.e. unless
`-O' not specified, since `-Wuninitialized' requires `-O'), and
implies `-Wunused' as well.
* `-Wunused' no longer gives spurious messages for unused `EXTERNAL'
names (since they are assumed to refer to block data program
units, to make use of libraries more reliable).
* Support `%LOC()' and `LOC()' of character arguments.
* Support null (zero-length) character constants and expressions.
* Support `f2c''s `IMAG()' generic intrinsic.
* Support `ICHAR()', `IACHAR()', and `LEN()' of character
expressions that are valid in assignments but not normally as
actual arguments.
* Support `f2c'-style `&' in column 1 to mean continuation line.
* Allow `NAMELIST', `EXTERNAL', `INTRINSIC', and `VOLATILE' in
`BLOCK DATA', even though these are not allowed by the standard.
* Allow `RETURN' in main program unit.
* Changes to Hollerith-constant support to obey Appendix C of the
standard:
- Now padded on the right with zeros, not spaces.
- Hollerith "format specifications" in the form of arrays of
non-character allowed.
- Warnings issued when non-blank truncation occurs when
converting to another type.
- When specified as actual argument, now passed by reference to
`INTEGER' (padded on right with spaces if constant too small,
otherwise fully intact if constant wider the `INTEGER' type)
instead of by value.
*Warning:* `f2c' differs on the interpretation of `CALL FOO(1HX)',
which it treats exactly the same as `CALL FOO('X')', but which the
standard and `g77' treat as `CALL FOO(%REF('X '))' (padded with
as many blanks as necessary to widen to `INTEGER'), essentially.
* Changes and fixes to typeless-constant support:
- Now treated as a typeless double-length `INTEGER' value.
- Warnings issued when overflow occurs.
- Padded on the left with zeros when converting to a larger
type.
- Should be properly aligned and ordered on the target machine
for whatever type it is turned into.
- When specified as actual argument, now passed as reference to
a default `INTEGER' constant.
* `%DESCR()' of a non-`CHARACTER' expression now passes a pointer to
the expression plus a length for the expression just as if it were
a `CHARACTER' expression. For example, `CALL FOO(%DESCR(D))',
where `D' is `REAL*8', is the same as `CALL FOO(D,%VAL(8)))'.
* Name of multi-entrypoint master function changed to incorporate
the name of the primary entry point instead of a decimal value, so
the name of the master function for `SUBROUTINE X' with alternate
entry points is now `__g77_masterfun_x'.
* Remove redundant message about zero-step-count `DO' loops.
* Clean up diagnostic messages, shortening many of them.
* Fix typo in `g77' man page.
* Clarify implications of constant-handling bugs in `f/BUGS'.
* Generate better code for `**' operator with a right-hand operand of
type `INTEGER'.
* Generate better code for `SQRT()' and `DSQRT()', also when
`-ffast-math' specified, enable better code generation for `SIN()'
and `COS()'.
* Generate better code for some kinds of array references.
* Speed up lexing somewhat (this makes the compilation phase
noticably faster).
File: ^.!gcc.docs.fortran.g77, Node: Changes, Next: Language, Prev: News, Up: Top
User-visible Changes
********************
To find out about existing bugs and ongoing plans for GNU Fortran,
on Internet do `finger -l fortran@gnu.ai.mit.edu' or whatever is the
equivalent on your system. (You might need to use the address
`fortran@gate-1.gnu.ai.mit.edu' instead, or use `gate-2', `gate-3',
`gate-4', and so on, instead of `gate-1'.)
Alternatively, retrieve `gnu.ai.mit.edu:/g77.plan' via anonymous
ftp, or if you cannot do that, email `fortran@gnu.ai.mit.edu' asking
for a recent copy of the GNU Fortran `.plan' file. (The `finger'
command shown above obtains the most recent copy of all these methods.)
In 0.5.18:
==========
* The `BYTE' and `WORD' statements now are supported, to a limited
extent.
* `INTEGER*1', `INTEGER*2', `INTEGER*8', and their `LOGICAL'
equivalents, now are supported to a limited extent. Among the
missing elements are complete intrinsic and constant support.
* Support automatic arrays in procedures. For example, `REAL A(N)',
where `A' is not a dummy argument, specifies that `A' is an
automatic array. The size of `A' is calculated from the value of
`N' each time the procedure is called, that amount of space is
allocated, and that space is freed when the procedure returns to
its caller.
* Add `-fno-zeros' option, enabled by default, to reduce
compile-time CPU and memory usage for code that provides initial
zero values for variables and arrays.
* Introduce three new options that apply to all compilations by
`g77'-aware GNU compilers--`-fmove-all-movables',
`-freduce-all-givs', and `-frerun-loop-opt'--which can improve the
run-time performance of some programs.
* Replace much of the existing documentation with a single Info
document.
* New option `-fno-second-underscore'.
In 0.5.17:
==========
* The `ERF()' and `ERFC()' intrinsics now are generic intrinsics,
mapping to `ERF'/`DERF' and `ERFC'/`DERFC', respectively. *Note:*
Use `INTRINSIC ERF,ERFC' in any code that might reference these as
generic intrinsics, to improve the likelihood of diagnostics
(instead of subtle run-time bugs) when using compilers that don't
support these as intrinsics.
* New option `-Wsurprising'.
* DO loops with non-`INTEGER' variables now diagnosed only when
`-Wsurprising' specified. Previously, this was diagnosed *unless*
`-fpedantic' or `-fugly' was specified.
In 0.5.16:
==========
* `libf2c' changed to output a leading zero (0) digit for
floating-point values output via list-directed and formatted
output (to bring `g77' more in line with many existing Fortran
implementations--the ANSI FORTRAN 77 standard leaves this choice
to the implementation).
* `libf2c' no longer built with debugging information intact, making
it much smaller.
* Automatic installation of the `g77' command now works.
* Diagnostic messages now more informative, a la `gcc', including
messages like `In function `foo':' and `In file included from...:'.
* New group of intrinsics called `unix', including `ABORT', `DERF',
`DERFC', `ERF', `ERFC', `EXIT', `FLUSH', `GETARG', `GETENV',
`SIGNAL', and `SYSTEM'.
* `-funix-intrinsics-{delete,hide,disable,enable}' options added.
* `-fno-underscoring' option added.
* `--driver' option added to the `g77' command.
* Support for the `gcc' options `-fident' and `-fno-ident' added.
* `g77 -v' returns much more version info, making the submission of
better bug reports easily.
* Many improvements to the `g77' command to better fulfill its role
as a front-end to the `gcc' driver. For example, `g77' now
recognizes `--version' as a verbose way of specifying `-v'.
* Compiling preprocessed (`*.F' and `*.fpp') files now results in
better diagnostics and debugging information, as the
source-location info now is passed all the way through the
compilation process instead of being lost.
In 0.5.15:
==========
* `-ffixed-line-length-N' option introduced.
In 0.5.14:
==========
* Support for gcc's `-I' option added.
* `-fbackslash' option added.
* `-fugly-args' option enabled by default (allows `CALL
FOO(4HABCD)').
* `-fugly-init' option added.
* `-finit-local-zero' option added.
* Support for the `gcc' option `-Wimplicit' added.
* `-Wall' now implies `-Wunused' and, when `-O' is specified,
`-Wuninitialized'.
* Hollerith constants as actual arguments now are passed by reference
instead of by value--so `CALL FOO(4HABCD)' now is compiled exactly
the same as `CALL FOO(%REF('ABCD'))', instead of as `CALL
FOO(%VAL('ABCD'))'.
* Hollerith constants converted to larger types now are padded on the
right with spaces. When converted to smaller types, warnings are
issued if non-spaces are truncated on the right.
* Format specifications of arrays of types other than `CHARACTER' are
allowed in I/O statements, such as when they contain Hollerith
data.
* Typeless constants as actual arguments now are passed by reference
to an `INTEGER' version of the constant instead of by value.
* Typeless constants converted to larger types are padded on the left
with zeros. When converted to smaller types, warnings are issued
if non-zero bits are truncated on the left.
* `%DESCR()' of a non-`CHARACTER' expression treats the expression
as if it were `CHARACTER', passing both a pointer to the expression
and the length of the type of the expression in bytes, by value,
in the "hidden" list of lengths used for `CHARACTER' arguments.
* The `ICHAR()', `IACHAR()', and `LEN()' intrinsics now accept
character expressions involving concatenation of assumed-length
dummy arguments.
* Block data program units now may contain `NAMELIST', `EXTERNAL',
`INTRINSIC', and `VOLATILE' statements.
* Zero-length character expressions now supported.
* Support for the `f2c' intrinsic `IMAG()' added.
* `INCLUDE' statement restrictions, such as no continuation lines
allowed, now lifted.
File: ^.!gcc.docs.fortran.g77, Node: Language, Next: Installation, Prev: Changes, Up: Top
The GNU Fortran Language
************************
GNU Fortran supports a variety of extensions to, and dialects of,
the Fortran language. Its primary base is the ANSI FORTRAN 77 standard.
It offers some extensions that are popular among users of UNIX `f77'
and `f2c' compilers, some that are popular among users of other
compilers (such as Digital products), some that are popular among users
of the newer Fortran 90 standard, and some that are introduced by GNU
Fortran.
Part of what defines a particular implementation of a Fortran
system, such as `g77', is the particular characteristics of how it
supports types, constants, and so on. Much of this is left up to the
implementation by the various Fortran standards and accepted practice
in the industry.
* Menu:
* Standard Support:: Degree of support for the ANSI FORTRAN 77 standard.
* Extensions:: Extensions to GNU Fortran.
* Types:: Data types.
* Constants:: Constants and their types.
* Source Form:: Form of source files (fixed, free, and so on).
* Pedantic Compilation:: Warnings about non-standard constructs.
* Case Sensitivity:: Uppercase and lowercase in source files.
* Intrinsics:: How intrinsics are grouped for easy management.
* Dialects:: Dialects supported by GNU Fortran.
* Object Compatibility:: Compatibility issues for code generated by `g77'.
* Distensions:: Misfeatures supported by GNU Fortran.
File: ^.!gcc.docs.fortran.g77, Node: Standard Support, Next: Extensions, Up: Language
ANSI FORTRAN 77 Standard Support
================================
GNU Fortran supports ANSI FORTRAN 77 with the following caveats:
* No passing of an external procedure as an actual argument if the
procedure's type is declared `CHARACTER*(*)'. For example:
CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END
It isn't clear whether the standard considers this conforming.
Note that it is unlikely that any production Fortran code tries to
use this unsupported construct.
* No passing of a dummy procedure as an actual argument if the
procedure's type is declared `CHARACTER*(*)'.
SUBROUTINE BAR(CFUNC)
CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END
It isn't clear whether the standard considers this conforming.
Note that it is unlikely that any production Fortran code tries to
use this unsupported construct.
* The `DO' variable for an implied-`DO' construct in a `DATA'
statement may not be used as the `DO' variable for an outer
implied-`DO' construct. For example, this fragment is disallowed
by `g77':
DATA ((A(I, I), I= 1, 10), I= 1, 10)/.../
This also is disallowed by Fortran 90, as it offers no additional
capabilities and would have a variety of possible meanings.
Note that it is *very* unlikely that any production Fortran code
tries to use this unsupported construct.
* An array element initializer in an implied-`DO' construct in a
`DATA' statement must contain at least one reference to the `DO'
variables of each outer implied-`DO' construct. For example, this
fragment is disallowed by `g77':
DATA (A, I= 1, 1)/1./
This also is disallowed by Fortran 90, as FORTRAN 77's more
permissive requirements offer no additional capabilities.
However, `g77' doesn't necessarily diagnose all cases where this
requirement is not met.
Note that it is *very* unlikely that any production Fortran code
tries to use this unsupported construct.
In summary, the only ANSI FORTRAN 77 features `g77' doesn't support
are those that are probably rarely used in actual code, some of which
are explicitly disallowed by the Fortran 90 standard.
File: ^.!gcc.docs.fortran.g77, Node: Extensions, Next: Types, Prev: Standard Support, Up: Language
GNU Fortran Extensions
======================
GNU Fortran supports ANSI FORTRAN 77 plus:
* `LOC()', if `-funix-intrinsics-enable' is in force.
* `%LOC', `%VAL', `%REF', and `%DESCR'--where `%DESCR' currently
means the same thing as passing the argument as if it were a
`CHARACTER' variable (with the phantom length argument appended to
the argument list).
* MIL-STD 1753 features (`IAND', `IOR', `MVBITS', `DO WHILE', `END
DO', and so on).
* `NAMELIST'.
* Most `f2c' intrinsics (`AND', `OR', `LSHIFT', `RSHIFT', and so on).
* `DOUBLE COMPLEX' and related intrinsics (standard and `f2c'
varieties).
* Various Fortran 90 features, such as `CYCLE', `EXIT', `SELECT
CASE' (except for `CHARACTER' types).
* Various DEC VAX/VMS FORTRAN v4.0 features (loosely called VXT
extensions).
* Various `f2c' features.
* Source files that are uppercase-only (enforced), lowercase-only
(enforced), caseless, and various other combinations as chosen via
command-line options.
* Arbitrary (limited only by available memory) number of
continuation lines.
* Use of `&' in column 1 to indicate a continuation line (as
supported by `f2c').
* Dollar signs (`$') in identifiers (other than as the first
character) when the `-fdollar-ok' option is specified.
When `-ff90' is specified, the language dialect changes as follows:
* The type of `REAL(Z)', where `Z' is type `DOUBLE COMPLEX', is
`DOUBLE PRECISION' instead of `REAL'.
* Zero-length `CHARACTER' entities are accepted, even when
`-fpedantic' is specified.
* Zero-size array dimensions (as in `INTEGER I(10,20,4:2)') are
accepted, although these are not supported by `libf2c', so
diagnostics are nevertheless produced for `g77'.
* `DOUBLE COMPLEX' (explicit or implicit) is accepted, even when
`-fpedantic' is specified.
* Substrings of constants (as in `'hello'(3:5)') are accepted, even
when `-fpedantic' is specified.
* `DATA' statements are allowed to precede executable statements,
even when `-fpedantic' specified.
Note that this does not allow all possible means of specifying
further attributes via specification statements for a variable
after it has been given an initial value via `DATA' or a
type-declaration statement. For example, after `DATA I/1/',
`INTEGER I' is not permitted, but `INTEGER J' is permitted.
* Use of a semicolon (`;') as a statement separator is accepted,
even when `-fpedantic' specified (so `CALL FOO; CALL BAR' works).
* Underscores (`_') are accepted in symbol names (except as the
first character, since Fortran 90 provides a different
interpretation for certain cases where that would occur--though
`g77' does not yet support that interpretation).
File: ^.!gcc.docs.fortran.g77, Node: Types, Next: Constants, Prev: Extensions, Up: Language
Types
=====
Fortran implementations have a fair amount of freedom given them by
the standard as far as how much storage space is used and how much
precision is offered by the various types such as `LOGICAL', `INTEGER',
`REAL', `DOUBLE PRECISION', `COMPLEX', and `CHARACTER'. Further, many
compilers offer so-called `*N' notation, but the interpretation of N
varies across compilers and target architectures.
The standard requires that `LOGICAL', `INTEGER', and `REAL' occupy
the same amount of storage space, and that `COMPLEX' and `DOUBLE
PRECISION' take twice as much storage space as `REAL'. Further, it
requires that `COMPLEX' entities be ordered such that when a `COMPLEX'
variable is storage-associated (such as via `EQUIVALENCE') with a
two-element `REAL' array named `R', `R(1)' corresponds to the real
element and `R(2)' to the imaginary element of the `COMPLEX' variable.
No particular requirements as to precision of any of these are placed on
the implementation, nor is the relationship of storage sizes of these
types to the `CHARACTER' type specified by the standard.
`g77' follows the above requirements, warning when compiling a
program requires placement of items in memory that contradict the
requirements of the target architecture. (For example, a program can
require placement of a `DOUBLE PRECISION' on a boundary that is not an
even multiple of its size, but still an even multiple of the size of a
`REAL' variable. On some target architectures, using the canonical
mapping of Fortran types to underlying architectural types, such
placement is prohibited by the machine definition or the Application
Binary Interface (ABI) in force for the configuration defined for
building `gcc' and `g77'. `g77' warns about such situations when it
encounters them.)
`g77' follows consistent rules for configuring the mapping between
Fortran types, including the `*N' notation, and the underlying
architectural types as accessed by a similarly-configured applicable
version of the `gcc' compiler. These rules offer a widely portable,
consistent Fortran/C environment, although they might well conflict
with the expectations of users of Fortran compilers designed and
written for particular architectures.
These rules are based on the configuration that is in force for the
version of `gcc' built in the same release as `g77' (and which was
therefore used to build both the `g77' compiler components and the
`libf2c' run-time library):
`REAL'
Same as `float' type.
`DOUBLE PRECISION'
Same as whatever floating-point type that is twice the size of a
`float'--usually, this is a `double'.
`INTEGER'
Same as an integral type that is occupies the same amount of
memory storage `float'--usually, this is either an `int' or a
`long int'.
`LOGICAL'
Same `gcc' type as `INTEGER'.
`COMPLEX'
Two `REAL' scalars (one for the real part followed by one for the
imaginary part).
`DOUBLE COMPLEX'
Two `DOUBLE PRECISION' scalars.
`NUMERIC-TYPE*N'
(Where NUMERIC-TYPE is any type other than `CHARACTER'.) Same as
whatever `gcc' type occupies N times the storage space of a `gcc'
`char' item.
`NUMERIC-TYPE(KIND=N)'
N=1 corresponds to `REAL', `INTEGER', `LOGICAL', `COMPLEX'. N=2
corresponds to `DOUBLE PRECISION', `DOUBLE COMPLEX', and, for
integral types, `char' (usually `INTEGER*1' and `LOGICAL*1'). N=3
corresponds to `short' for integral types (usually `INTEGER*2' and
`LOGICAL*2'). N=4 corresponds to `long long' for integral types
(this usually means `INTEGER*8' and `LOGICAL*8').
Note that these are proposed correspondences and might change in
future versions of `g77'--avoid writing code depending on them.
For now, `g77' does not support numeric types other than the ones
listed above. So, on a typical 32-bit machine, only `INTEGER*4',
`REAL*4', `LOGICAL*4', `COMPLEX*8', and so on, will work. Other types
supported by `g77' are derived from gcc types such as `char', `short',
`int', `long int', `long long int', `long double', and so on. That is,
whatever types `gcc' already supports, `g77' probably will support in a
future version. The rules for the `NUMERIC-TYPE*N' notation will apply
to the new types, and new values for `NUMERIC-TYPE(KIND=N)' will be
assigned in a way that encourages clarity, consistency, and portability.
File: ^.!gcc.docs.fortran.g77, Node: Constants, Next: Source Form, Prev: Types, Up: Language
Constants
=========
`g77' strictly assigns types to all constants not documented as
"typeless" (the typeless constants include things like `Z'1'').
Context is never a determining factor for the type, and hence the
interpretation, of a typed constant. Examples: `1' is always type
`INTEGER', `3.141592653545256234' is always type `REAL' (even if the
additional precision specified is lost, and even when used in a `DOUBLE
PRECISION' context), `1E0' is always type `REAL', and `1D0' is always
type `DOUBLE PRECISION'.
Many other Fortran compilers attempt to assign types to typed
constants based on their context. This results in hard-to-find bugs,
nonportable code, and is not in the spirit (though it strictly follows
the letter) of the 77 and 90 standards. `g77' will not support these
dangerous semantics, but might offer, in a future release, explicit
constructs by which a wider variety of typeless constants may be
specified, and/or user-requested warnings indicating places where `g77'
might differ from how other compilers assign types to constants.
File: ^.!gcc.docs.fortran.g77, Node: Source Form, Next: Pedantic Compilation, Prev: Constants, Up: Language
Source Form
===========
The `-ffree-form' (aka `-fno-fixed-form') and `-ffixed-form' (aka
`-fno-free-form') command-line options govern how the source file is
interpreted. Fixed form corresponds to classic ANSI FORTRAN 77 (plus
popular extensions, such as allowing tabs) and Fortran 90's fixed form.
Free form corresponds to Fortran 90's free form (though possibly not
entirely up-to-date, and without complaining about some things that for
which Fortran 90 requires diagnostics, such as `R = 3 . 1').
The way a Fortran compiler views source files depends entirely on the
implementation choices made for the compiler. GNU Fortran currently
tries to be somewhat like a few popular compilers (`f2c', DEC Fortran,
and so on), though a cleaner default definition along with more
flexibility offered by command-line options is likely to be offered in
version 0.6.
Here are some facts regarding the way `g77' interprets source lines:
* Carriage returns (`\r') in source lines are ignored. This is
somewhat different from `f2c', which seems to treat them as spaces
outside character/Hollerith constants, and encodes them as `\r'
inside such constants.
* A source line with a TAB character anywhere in it is treated as
entirely significant--however long it is--instead of ending in
column 72 (for fixed-form source) or 132 (for free-form source).
This also is different from `f2c', which encodes tabs as `\t' (the
ASCII TAB character) inside character and Hollerith constants, but
nevertheless seems to treat the column position as if it had been
affected by the canonical tab positioning.
`g77' effectively translates tabs to the appropriate number of
spaces (a la the default for the UNIX `expand' command) before
doing any other processing, other than (currently) noting whether
a tab was found on a line and using this info to decide how to
interpret the length of the line and continued constants.
Note that this default behavior probably will change for version
0.6, when it will presumably be available via a command-line
option. The default as of version 0.6 is planned to be a "pure
visual" model, where tabs are immediately converted to spaces and
otherwise have no effect, so the way a typical user sees source
lines produces a consistent result no matter how the spacing in
those source lines is actually implemented via tabs, spaces, and
trailing tabs/spaces before newline. Command-line options are
likely to be added to specify whether all or just-tabbed lines are
to be extended to 132 or full input-line length, and perhaps even
an option will be added to specify the truncated-line behavior to
which some Digital compilers default (and which affects the way
continued character/Hollerith constants are interpreted).
* Source lines shorter than the applicable fixed length are treated
as if they were padded with spaces to that length.
This affects only continued character and Hollerith constants, and
is a different interpretation than provided by some other popular
compilers (although a bit more consistent with the traditional
punched-card basis of Fortran and the way the Fortran standard
expressed fixed source form).
`g77' might someday offer an option to warn about cases where
differences might be seen as a result of this treatment, and
perhaps an option to specify the alternate behavior as well.
Note that this padding cannot apply to lines that are effectively
of infinite length--such lines are specified using command-line
options like `-ffixed-line-length-none', for example.
File: ^.!gcc.docs.fortran.g77, Node: Pedantic Compilation, Next: Case Sensitivity, Prev: Source Form, Up: Language
Pedantic Compilation
====================
The `-fpedantic' command-line option specifies that `g77' is to warn
about certain non-standard constructs. This is useful for finding some
extensions `g77' accepts that other compilers might not accept. (Note
that the `-pedantic' and `-pedantic-errors' options always imply
`-fpedantic'.)
With `-ff90' in force along with `-fpedantic', some constructs are
accepted that result in diagnostics when `-fno-f90' and `-fpedantic'
are both in force. *Note GNU Fortran Extensions: Extensions, for
information on those constructs.
The constructs for which `g77' issues diagnostics when `-fpedantic'
and `-fno-f90' are in force are:
* Automatic arrays, as in `REAL A(N)', where `A' is not a dummy
argument.
* `READ (5), I' and `WRITE (10), J'--the standard disallows the
comma in each case, while allowing it in `READ 10, I', but many
compilers (including `f2c') allow the superfluous comma.
* `DOUBLE COMPLEX', either explicitly (via explicit or `IMPLICIT'
statement) or implicitly (as in `C*D', where `C' is `COMPLEX' and
`D' is `DOUBLE PRECISION', which is prohibited by the standard
because it should produce a non-standard `DOUBLE COMPLEX' result).
* Automatic conversion of numeric expressions to `INTEGER' in
contexts such as:
- Array-reference indexes.
- Alternate-return values.
- Computed `GOTO'.
- `FORMAT' run-time expressions (not yet supported).
- Dimension lists in specification statements.
- Numbers for I/O statements (such as `READ (UNIT=3.2), I')
- Sizes of `CHARACTER' entities in specification statements.
- Kind types in specification entities (a Fortran 90 feature).
- Initial, terminal, and incrementation parameters for
implied-`DO' constructs in `DATA' statements.
* Automatic conversion of `LOGICAL' expressions to `INTEGER' in
contexts such as arithmetic `IF' (where `COMPLEX' expressions are
disallowed anyway).
* Substring operators applied to character constants and named
constants (such as `PRINT *,'hello'(3:5)', which would print
`llo').
* Null argument passed to statement function (as in `PRINT
*,FOO(,3)').
* Differences between program units regarding whether a given
`COMMON' area is `SAVE'd (for targets where program units in a
single source file are "glued" together as they typically are for
UNIX development environments).
* Differences between named-`COMMON'-block sizes between program
units.
* Specification statements following first `DATA' statement (normally
`DATA I/1/' may be followed by `INTEGER J', though not `INTEGER
I', but `-fpedantic' disables use of both cases.
* Semicolon as statement separator (as in `CALL FOO; CALL BAR').
* Use of `&' in column 1 of fixed-form source (indicates
continuation).
* Use of `CHARACTER' constants to initialize numeric entities, and
vice versa.
* Expressions having two arithmetic operators in a row, such as
`X*-Y'.
If `-fpedantic' is specified along with `-ff90', the following
constructs result in diagnostics:
* Use of semicolons on line with INCLUDE statement.
File: ^.!gcc.docs.fortran.g77, Node: Case Sensitivity, Next: Intrinsics, Prev: Pedantic Compilation, Up: Language
Case Sensitivity
================
GNU Fortran offers the programmer way too much flexibility in
deciding how source files are to be treated vis-a-vis uppercase and
lowercase characters. There are 66 useful settings that affect case
sensitivity, plus 10 settings that are nearly useless, with the
remaining 116 settings being either redundant or useless.
None of these settings have any effect on the contents of comments
(the text after a `c' or `C' in Column 1, for example) or of character
or Hollerith constants. Note that things like the `E' in the statement
`CALL FOO(3.2E10)' and the `TO' in `ASSIGN 10 TO LAB' are considered
built-in keywords.
Low-level switches are identified in this discussion thusly:
A Source Case Conversion
0 Preserve (see Note 1)
1 Convert to Upper Case
2 Convert to Lower Case
B Built-in Keyword Matching:
0 Match Any Case (per-character basis)
1 Match Upper Case Only
2 Match Lower Case Only
3 Match InitialCaps Only (see tables for spellings)
C Built-in Intrinsic Matching:
0 Match Any Case (per-character basis)
1 Match Upper Case Only
2 Match Lower Case Only
3 Match InitialCaps Only (see tables for spellings)
D User-defined Symbol Possibilities (warnings only)
0 Allow Any Case (per-character basis)
1 Allow Upper Case Only
2 Allow Lower Case Only
3 Allow InitialCaps Only (see Note 2)
Note 1: `g77' eventually will support `NAMELIST' in a manner that is
consistent with these source switches--in the sense that input will be
expected to meet the same requirements as source code in terms of
matching symbol names and keywords (for the exponent letters).
Currently, however, `NAMELIST' is supported `libf2c', which
uppercases `NAMELIST' input and symbol names for matching. This means
not only that `NAMELIST' output currently shows symbol (and keyword)
names in uppercase even if lower-case source conversion (option A2) is
selected, but that `NAMELIST' cannot be adequately supported when
source case preservation (option A0) is selected.
If A0 is selected, a warning message will be output for each
`NAMELIST' statement to this effect. The behavior of the program is
undefined at run time if two or more symbol names appear in a given
`NAMELIST' such that the names are identical when converted to upper
case (e.g. `NAMELIST /X/ VAR, Var, var'). For complete and total
elegance, perhaps there should be a warning when option A2 is selected,
since the output of NAMELIST is currently in uppercase but will someday
be lowercase (when a `libg77' is written), but that seems to be
overkill for a product in beta test.
Note 2: Rules for InitialCaps names are:
- Must be a single uppercase letter, *or*
- Must start with an uppercase letter and contain at least one
lowercase letter.
So `A', `Ab', `ABc', `AbC', and `Abc' are valid InitialCaps names,
but `AB', `A2', and `ABC' are not. Note that most, but not all,
built-in names meet these requirements--the exceptions are some of the
two-letter format specifiers, such as `BN' and `BZ'.
Here are the names of the corresponding command-line options:
A0: -fsource-case-preserve
A1: -fsource-case-upper
A2: -fsource-case-lower
B0: -fmatch-case-any
B1: -fmatch-case-upper
B2: -fmatch-case-lower
B3: -fmatch-case-initcap
C0: -fintrin-case-any
C1: -fintrin-case-upper
C2: -fintrin-case-lower
C3: -fintrin-case-initcap
D0: -fsymbol-case-any
D1: -fsymbol-case-upper
D2: -fsymbol-case-lower
D3: -fsymbol-case-initcap
Useful combinations of the above settings, along with abbreviated
option names that set some of these combinations all at once:
1: A0-- B0--- C0--- D0--- -fcase-preserve
2: A0-- B0--- C0--- D-1--
3: A0-- B0--- C0--- D--2-
4: A0-- B0--- C0--- D---3
5: A0-- B0--- C-1-- D0---
6: A0-- B0--- C-1-- D-1--
7: A0-- B0--- C-1-- D--2-
8: A0-- B0--- C-1-- D---3
9: A0-- B0--- C--2- D0---
10: A0-- B0--- C--2- D-1--
11: A0-- B0--- C--2- D--2-
12: A0-- B0--- C--2- D---3
13: A0-- B0--- C---3 D0---
14: A0-- B0--- C---3 D-1--
15: A0-- B0--- C---3 D--2-
16: A0-- B0--- C---3 D---3
17: A0-- B-1-- C0--- D0---
18: A0-- B-1-- C0--- D-1--
19: A0-- B-1-- C0--- D--2-
20: A0-- B-1-- C0--- D---3
21: A0-- B-1-- C-1-- D0---
22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper
23: A0-- B-1-- C-1-- D--2-
24: A0-- B-1-- C-1-- D---3
25: A0-- B-1-- C--2- D0---
26: A0-- B-1-- C--2- D-1--
27: A0-- B-1-- C--2- D--2-
28: A0-- B-1-- C--2- D---3
29: A0-- B-1-- C---3 D0---
30: A0-- B-1-- C---3 D-1--
31: A0-- B-1-- C---3 D--2-
32: A0-- B-1-- C---3 D---3
33: A0-- B--2- C0--- D0---
34: A0-- B--2- C0--- D-1--
35: A0-- B--2- C0--- D--2-
36: A0-- B--2- C0--- D---3
37: A0-- B--2- C-1-- D0---
38: A0-- B--2- C-1-- D-1--
39: A0-- B--2- C-1-- D--2-
40: A0-- B--2- C-1-- D---3
41: A0-- B--2- C--2- D0---
42: A0-- B--2- C--2- D-1--
43: A0-- B--2- C--2- D--2- -fcase-strict-lower
44: A0-- B--2- C--2- D---3
45: A0-- B--2- C---3 D0---
46: A0-- B--2- C---3 D-1--
47: A0-- B--2- C---3 D--2-
48: A0-- B--2- C---3 D---3
49: A0-- B---3 C0--- D0---
50: A0-- B---3 C0--- D-1--
51: A0-- B---3 C0--- D--2-
52: A0-- B---3 C0--- D---3
53: A0-- B---3 C-1-- D0---
54: A0-- B---3 C-1-- D-1--
55: A0-- B---3 C-1-- D--2-
56: A0-- B---3 C-1-- D---3
57: A0-- B---3 C--2- D0---
58: A0-- B---3 C--2- D-1--
59: A0-- B---3 C--2- D--2-
60: A0-- B---3 C--2- D---3
61: A0-- B---3 C---3 D0---
62: A0-- B---3 C---3 D-1--
63: A0-- B---3 C---3 D--2-
64: A0-- B---3 C---3 D---3 -fcase-initcap
65: A-1- B01-- C01-- D01-- -fcase-upper
66: A--2 B0-2- C0-2- D0-2- -fcase-lower
Number 22 is the "strict" ANSI FORTRAN 77 model wherein all input
(except comments, character constants, and Hollerith strings) must be
entered in uppercase. Use `-fcase-strict-upper' to specify this
combination.
Number 43 is like Number 22 except all input must be lowercase. Use
`-fcase-strict-lower' to specify this combination.
Number 65 is the "classic" ANSI FORTRAN 77 model as implemented on
many non-UNIX machines whereby all the source is translated to
uppercase. Use `-fcase-upper' to specify this combination.
Number 66 is the "canonical" UNIX model whereby all the source is
translated to lowercase. Use `-fcase-lower' to specify this
combination.
There are a few nearly useless combinations:
67: A-1- B01-- C01-- D--2-
68: A-1- B01-- C01-- D---3
69: A-1- B01-- C--23 D01--
70: A-1- B01-- C--23 D--2-
71: A-1- B01-- C--23 D---3
72: A--2 B01-- C0-2- D-1--
73: A--2 B01-- C0-2- D---3
74: A--2 B01-- C-1-3 D0-2-
75: A--2 B01-- C-1-3 D-1--
76: A--2 B01-- C-1-3 D---3
The above allow some programs to be compiled but with restrictions
that make most useful programs impossible: Numbers 67 and 72 warn about
*any* user-defined symbol names (such as `SUBROUTINE FOO'); Numbers 68
and 73 warn about any user-defined symbol names longer than one
character that don't have at least one non-alphabetic character after
the first; Numbers 69 and 74 disallow any references to intrinsics; and
Numbers 70, 71, 75, and 76 are combinations of the restrictions in
67+69, 68+69, 72+74, and 73+74, respectively.
All redundant combinations are shown in the above tables anyplace
where more than one setting is shown for a low-level switch. For
example, `B0-2-' means either setting 0 or 2 is valid for switch B.
The "proper" setting in such a case is the one that copies the setting
of switch A--any other setting might slightly reduce the speed of the
compiler, though possibly to an unmeasurable extent.
All remaining combinations are useless in that they prevent
successful compilation of non-null source files (source files with
something other than comments).
File: ^.!gcc.docs.fortran.g77, Node: Intrinsics, Next: Dialects, Prev: Case Sensitivity, Up: Language
Intrinsics
==========
A given specific intrinsic belongs in one or more groups. Each group
is deleted, disabled, hidden, or enabled by default or a command-line
option. The meaning of each term follows.
Deleted
No intrinsics are recognized as belonging to that group.
Disabled
Intrinsics are recognized as belonging to the group, but
references to them (other than via the `INTRINSIC' statement) are
disallowed through that group.
Hidden
Intrinsics in that group are recognized and enabled (if
implemented) *only* if the first mention of the actual name of an
intrinsic in a program unit is in an `INTRINSIC' statement.
Enabled
Intrinsics in that group are recognized and enabled (if
implemented).
The distinction between deleting and disabling a group is illustrated
by the following example. Assume intrinsic `FOO' belongs only to group
`FGR'. If group `FGR' is deleted, the following program unit will
successfully compile, because `FOO()' will be seen as a reference to an
external function named `FOO':
PRINT *, FOO()
END
If group `FGR' is disabled, compiling the above program will produce
diagnostics, either because the `FOO' intrinsic is improperly invoked
or, if properly invoked, it is not enabled. To change the above
program so it references an external function `FOO' instead of the
disabled `FOO' intrinsic, add the following line to the top:
EXTERNAL FOO
So, deleting a group tells `g77' to pretend as though the intrinsics in
that group do not exist at all, whereas disabling it tells `g77' to
recognize them as (disabled) intrinsics in intrinsic-like contexts.
Hiding a group is like enabling it, but the intrinsic must be first
named in an `INTRINSIC' statement to be considered a reference to the
intrinsic rather than to an external procedure. This might be the
"safest" way to treat a new group of intrinsics when compiling old
code, because it allows the old code to be generally written as if
those new intrinsics never existed, but to be changed to use them by
inserting `INTRINSIC' statements in the appropriate places. However,
it should be the goal of development to use `EXTERNAL' for all names of
external procedures that might be intrinsic names.
If an intrinsic is in more than one group, it is enabled if any of
its containing groups are enabled; if not so enabled, it is hidden if
any of its containing groups are hidden; if not so hidden, it is
disabled if any of its containing groups are disabled; if not so
disabled, it is deleted. This extra complication is necessary because
some intrinsics, such as `IBITS', belong to more than one group, and
hence should be enabled if any of the groups to which they belong are
enabled, and so on.
The groups are:
`dcp'
`DOUBLE COMPLEX' intrinsics from the standards (F77, F90).
`f2c'
Intrinsics supported by AT&T's `f2c' converter and/or `libf2c'.
`f90'
Fortran 90 intrinsics.
`mil'
MIL-STD 1753 intrinsics (`MVBITS', `IAND', `BTEST', and so on).
`unix'
UNIX intrinsics (`IARGC', `EXIT', `ERF', and so on).
`vxt'
VAX/VMS FORTRAN (current as of v4) intrinsics.
File: ^.!gcc.docs.fortran.g77, Node: Dialects, Next: Object Compatibility, Prev: Intrinsics, Up: Language
GNU Fortran Dialects
====================
The `-fvxt-not-f90' and `-ff90-not-vxt' command-line options control
how `g77' interprets certain tokens and constructs that have different
meanings in VAX FORTRAN (circa v4) and Fortran 90. (Generally, this
manual uses the invented acronym VXT to refer to many popular VAX
FORTRAN extensions, though not necessarily those that are specific to
the VAX processor architecture or the VMS operating system. An
extension offered by a Digital Fortran product that also is offered by
several other Fortran products for different kinds of systems is
probably going to be considered for inclusion in `g77' someday, and is
considered a VXT extension.)
When `-ff90-not-vxt' is specified, the following interpretations are
made (and, when `-fvxt-not-f90' is in effect, the opposite
interpretations are made):
* Double-quote character (`"') delimits character constant just as
does apostrophe (`''), rather than beginning an octal constant of
`INTEGER' type.
* An exclamation point (`!') in column 5 of fixed-form source file
treated as a continuation character rather than the beginning of a
comment (as it does in any other column).
* `TYPE FOO' and `TYPE (FOO), BAR' statements are recognized as the
Fortran 90 variety, not I/O statements. (However, the F90 variety
is *not* supported, so this really just ensures that `g77' will
produce a diagnostic instead of trying to implement the VXT `TYPE'
statement--which currently is not supported either.)
File: ^.!gcc.docs.fortran.g77, Node: Object Compatibility, Next: Distensions, Prev: Dialects, Up: Language
Object Compatibility
====================
An individual Fortran source file can be compiled to an object
(`*.o') file instead of to the final program executable. This allows
several portions of a program to be compiled at different times and
linked together whenever a new version of the program is needed.
However, it introduces the issue of "object compatibility" across the
various object files (and libraries, or `*.a' files) that are linked
together to produce any particular exectable file.
Object compatibility is an issue when combining, in one program,
Fortran code compiled by more than one compiler (or more than one
configuration of a compiler). If the compilers disagree on how to
transform the names of procedures, there will normally be errors when
linking such programs. Worse, if the compilers agree on naming, but
disagree on issues like how to pass parameters, return arguments, and
lay out `COMMON' areas, the earliest detected errors might be the
incorrect results produced by the program (and that assumes these
errors are detected, which is not always the case).
Normally, `g77' generates code that is object-compatible with code
generated by a version of `f2c' configured (with, for example, `f2c.h'
definitions) to be generally compatible with `g77' as built by `gcc'.
(Normally, `f2c' will, by default, conform to the appropriate
configuration, but it is possible that older or perhaps even newer
versions of `f2c', or versions having certain configuration changes to
`f2c' internals, will produce object files that are incompatible with
`g77'.)
For example, a Fortran string subroutine argument will become two
arguments on the C side: a `char *' and an `int' length.
Much of this compatibility results from the fact that `g77' uses the
same run-time library, `libf2c', used by `f2c'.
Other compilers might or might not generate code that is
object-compatible with `libf2c' and current `g77', and some might offer
such compatibility only when explicitly selected via a command-line
option to the compiler.
* Menu:
* Dropping f2c Compatibility:: When speed is more important.
* Other Compilers:: Interoperation with code from other compilers.
File: ^.!gcc.docs.fortran.g77, Node: Dropping f2c Compatibility, Next: Other Compilers, Up: Object Compatibility
Dropping f2c Compatibility
--------------------------
Specifying `-fno-f2c' allows `g77' to generate, in some cases,
faster code, by not needing to allow to the possibility of linking with
code compiled by `f2c'.
For example, this affects how `REAL', `COMPLEX', and `DOUBLE
COMPLEX' functions are called. With `-fno-f2c', they are compiled as
returning the appropriate `gcc' type (`float', `__complex__ float',
`__complex__ double', in many configurations).
With `-ff2c' in force, they are compiled differently (with perhaps
slower run-time performance) to accommodate the restrictions inherent
in `f2c''s use of K&R C as an intermediate language--`REAL' functions
return double, while `COMPLEX' functions return `void' and use an extra
argument pointing to a place for the functions to return their values.
It is possible that, in some cases, leaving `-ff2c' in force might
produce faster code than using `-fno-f2c'. Feel free to experiment,
but remember to experiment with changing the way *entire programs and
their Fortran libraries are compiled* at a time, since this sort of
experimentation affects the interface of code generated for a Fortran
source file--that is, it affects object compatibility.
Note that `f2c' compatibility is a fairly static target to achieve,
though not necessarily perfectly so, since, like `g77', it is still
being improved. However, specifying `-fno-f2c' causes `g77' to
generate code that will probably be incompatible with code generated by
future versions of `g77' when the same option is in force. You should
make sure you are always able to recompile complete programs from
source code when upgrading to new versions of `g77' or `f2c',
especially when using options such as `-fno-f2c'.
Therefore, if you are using `g77' to compile libraries and other
object files for possible future use and you don't want to require
recompilation for future use with subsequent versions of `g77', you
might want to stick with `f2c' compatibility for now, and carefully
watch for any announcements about changes to the `f2c'/`libf2c'
interface that might affect existing programs (thus requiring
recompilation).
It is probable that a future version of `g77' will not, by default,
generate object files compatible with `f2c' and not use `libf2c'. If
you expect to depend on this compatibility in the long term, use the
options `-ff2c -ff2c-library' when compiling all of the applicable code.
This should either cause `g77' to produce compatible code (at the
expense of the availability of some features and performance), or at
the very least trigger compiler warning messages, in future versions of
`g77'.
File: ^.!gcc.docs.fortran.g77, Node: Other Compilers, Prev: Dropping f2c Compatibility, Up: Object Compatibility
Other Compilers
---------------
On systems with Fortran compilers other than `f2c' and `g77', code
compiled by `g77' is not expected to work well with code compiled by
the native compiler. (This is true for `f2c'-compiled objects as well.)
Libraries compiled with the native compiler probably will have to be
recompiled with `g77' to be used with `g77'-compiled code.
Reasons for such incompatibilities include:
* There might be differences in the way names of Fortran procedures
are translated for use in the system's object-file format. For
example, the statement `CALL FOO' might be compiled by `g77' to
call a procedure the linker `ld' sees given the name `_foo_',
while the apparently corresponding statement `SUBROUTINE FOO'
might be compiled by the native compiler to define the
linker-visible name `_foo', or `_FOO_', and so on.
* There might be subtle type mismatches which cause subroutine
arguments and function return values to get corrupted.
This is why simply getting `g77' to transform procedure names the
same way a native compiler does is not usually a good idea--unless
some effort has been made to ensure that, aside from the way the
two compilers transform procedure names, everything else about the
way they generate code for procedure interfaces is identical.
* Native compilers use libraries of private I/O routines which will
not be available at link time unless you have the native
compiler--and you would have to explicitly ask for them.
For example, on the Sun you would have to add `-L/usr/lang/SCx.x
-lF77 -lV77' to the link command.
File: ^.!gcc.docs.fortran.g77, Node: Distensions, Prev: Object Compatibility, Up: Language
Distensions
===========
The `-fugly' command-line options determine whether certain features
supported by VAX FORTRAN and other such compilers, but considered too
ugly to be in code that can be changed to use safer and/or more
portable constructs, are accepted. These are humorously referred to as
"distensions", extensions that just plain look ugly in the harsh light
of day.
The constructs enabled via `-fugly' include:
* Automatic conversion between `INTEGER' and `LOGICAL' as dictated by
context (typically implies nonportable dependencies on how a
particular implementation encodes `.TRUE.' and `.FALSE.').
* Use of typeless and Hollerith constants in non-standard places
(the "standard" here being the appendix in ANSI FORTRAN 77 and the
descriptions in MIL-STD 1753), plus in places controlled by
`-fugly-args' and `-fugly-init'.
* Use of a `LOGICAL' variable in `ASSIGN' and assigned-`GOTO'
statements.
* Use of a single trailing comma to mean "pass an extra trailing null
argument" in a list of actual arguments to a procedure other than a
statement function.
For example, `CALL FOO(,)' means "pass two null arguments" when
`-fugly' is used, rather than "pass one null argument".
The construct disabled via `-fno-ugly-args' is:
* Passing of typeless and Hollerith constants as actual arguments in
procedure invocations.
For example, `CALL FOO(4HABCD)'.
The constructs disabled by `-fno-ugly-init' are:
* Use of Hollerith and typeless constants in contexts where they set
initial (compile-time) values for variables, arrays, and named
constants--that is, `DATA' and `PARAMETER' statements, plus
type-declaration statements specifying initial values.
* In the same contexts as above, use of character constants to
initialize numeric items and vice versa (one constant per item).
* Use of Hollerith and typeless constants on the right-hand side of
assignment statements to numeric types, and in other contexts
(such as passing arguments to in invocations of intrinsic
procedures and statement functions) that are treated as
assignments to known types (the dummy arguments, in these cases).
File: ^.!gcc.docs.fortran.g77, Node: Installation, Next: Debugging and Interfacing, Prev: Language, Up: Top
Installing GNU Fortran
**********************
* Menu:
* Prerequisites:: Make sure your system is ready for `g77'.
* Problems Installing:: Known trouble areas.
* Quick Start:: The easier procedure for non-experts.
* Complete Installation:: For experts, or those who want to be: the details.
* Distributing Binaries:: If you plan on distributing your `g77'.
* Settings:: Some notes on `g77' internals.
The following information describes how to install `g77'.
The information in this file generally pertains to dealing with
*source* distributions of `g77' and `gcc'. It is possible that some of
this information will be applicable to some *binary* distributions of
these products--however, since these distributions are not made by the
maintainers of `g77', responsibility for binary distributions rests with
whoever built and first distributed them.
Nevertheless, efforts to make `g77' easier to both build and install
from source and package up as a binary distribution are ongoing.
File: ^.!gcc.docs.fortran.g77, Node: Prerequisites, Next: Problems Installing, Up: Installation
Prerequisites
=============
The procedures described to unpack, configure, build, and install
`g77' assume your system has certain programs already installed.
The following prerequisites should be met by your system before you
follow the `g77' installation instructions:
`gzip'
To unpack the `gcc' and `g77' distributions, you'll need the
`gunzip' utility in the `gzip' distribution. Most UNIX systems
already have `gzip' installed. If yours doesn't, you can get it
from the FSF.
Note that you'll need `tar' and other utilities as well, but all
UNIX systems have these. There are GNU versions of all these
available--in fact, a complete GNU UNIX system can be put together
on most systems, if desired.
`gcc-2.7.2.tar.gz'
You need to have this, or some other applicable, version of `gcc'
on your system. The version should be an exact copy of a
distribution from the FSF. It is approximately 7MB large.
If you've already unpacked `gcc-2.7.2.tar.gz' into a directory
(named `gcc-2.7.2') called the "source tree" for `gcc', you can
delete the distribution itself, but you'll need to remember to
skip any instructions to unpack this distribution.
Without an applicable `gcc' source tree, you cannot build `g77'.
You can obtain an FSF distribution of `gcc' from the FSF.
`g77-0.5.18.tar.gz'
You probably have already unpacked this distribution, or you are
reading an advanced copy of this manual, which is contained in
this distribution. This distribution approximately 1MB large.
You can obtain an FSF distribution of `g77' from the FSF, the same
way you obtained `gcc'.
100MB disk space
For a complete "bootstrap" build, about 100MB of disk space is
required for `g77' by the author's current Linux system.
Some juggling can reduce the amount of space needed; during the
bootstrap process, once Stage 3 starts, during which the version
of `gcc' that has been copied into the `stage2/' directory is used
to rebuild the system, you can delete the `stage1/' directory to
free up some space.
It is likely that many systems don't require the complete
bootstrap build, as they already have a recent version of `gcc'
installed. Such systems might be able to build `g77' with only
about 75MB of free space.
`patch'
Although you can do everything `patch' does yourself, by hand,
without much trouble, having `patch' installed makes installation
of new versions of GNU utilities such as `g77' so much easier that
it is worth getting. You can obtain `patch' the same way you
obtained `gcc' and `g77'.
In any case, you can apply patches by hand--patch files are
designed for humans to read them.
`make'
Your system must have `make', and you will probably save yourself
a lot of trouble if it is GNU `make' (sometimes referred to as
`gmake').
Your system must have a working C compiler.
*Note Installing GNU CC: (gcc)Installation, for more information
on prerequisites for installing `gcc'.
`bison'
If you do not have `bison' installed, you can usually work around
any need for it, since `g77' itself does not use it, and `gcc'
normally includes all files generated by running it in its
distribution. You can obtain `bison' the same way you obtained
`gcc' and `g77'.
*Note Missing bison?::, for information on how to work around not
having `bison'.
`makeinfo'
If you are missing `makeinfo', you can usually work around any
need for it. You can obtain `makeinfo' the same way you obtained
`gcc' and `g77'.
*Note Missing makeinfo?::, for information on getting around the
lack of `makeinfo'.
`root' access
To perform the complete installation procedures on a system, you
need to have `root' access to that system, or equivalent access.
Portions of the procedure (such as configuring and building `g77')
can be performed by any user with enough disk space and virtual
memory.
However, these instructions are oriented towards less-experienced
users who want to install `g77' on their own personal systems.
System administrators with more experience will want to determine
for themselves how they want to modify the procedures described
below to suit the needs of their installation.
File: ^.!gcc.docs.fortran.g77, Node: Problems Installing, Next: Quick Start, Prev: Prerequisites, Up: Installation
Problems Installing
===================
This is a list of problems (and some apparent problems which don't
really mean anything is wrong) that show up when configuring, building,
installing, or porting GNU Fortran.
*Note Installation Problems: (gcc)Installation Problems, for more
information on installation problems that can afflict either `gcc' or
`g77'.
* Menu:
* General Problems:: Problems afflicting most or all systems.
* Cross-compiler Problems:: Problems afflicting cross-compilation setups.
File: ^.!gcc.docs.fortran.g77, Node: General Problems, Next: Cross-compiler Problems, Up: Problems Installing
General Problems
----------------
* On SunOS systems, linking the `f771' program produces an error
message concerning an undefined symbol named `_strtoul'.
This is not a `g77' bug. *Note Patching GNU Fortran::, for
information on a workaround provided by `g77'.
The proper fix is either to upgrade your system to one that
provides a complete ANSI C environment, or improve `gcc' so that
it provides one for all the languages and configurations it
supports.
*Note:* In earlier versions of `g77', an automated workaround for
this problem was attempted. It worked for systems without
`_strtoul', substituting the incomplete-yet-sufficient version
supplied with `g77' for those systems. However, the automated
workaround failed mysteriously for systems that appeared to have
conforming ANSI C environments, and it was decided that, lacking
resources to more fully investigate the problem, it was better to
not punish users of those systems either by requiring them to work
around the problem by hand or by always substituting an incomplete
`strtoul()' implementation when their systems had a complete,
working one. Unfortunately, this meant inconveniencing users of
systems not having `strtoul()', but they're using obsolete (and
generally unsupported) systems anyway.
* It'd be helpful if `g77''s `Makefile.in' or `Make-lang.in' would
create the various `stageN' directories and their subdirectories,
so expert installers wouldn't have to reconfigure after cleaning
up.
* Improvements to the way `libf2c' is built could make building
`g77' as a cross-compiler easier--for example, passing and using
`LD' and `AR' in the appropriate ways.
* `g77' currently requires application of a patch file to the gcc
compiler tree (at least up through gcc version 2.7.0). The
necessary patches should be folded in to the mainline gcc
distribution.
(Some combinations of versions of `g77' and `gcc' might actually
*require* no patches, but the patch files will be provided anyway
as long as there are more changes expected in subsequent releases.
These patch files might contain unnecessary, but possibly helpful,
patches. As a result, it is possible this issue might never be
resolved, except by eliminating the need for the person
configuring `g77' to apply a patch by hand, by going to a more
automated approach (such as configure-time patching).
* It should be possible to build the runtime without building `cc1'
and other non-Fortran items, but, for now, an easy way to do that
is not yet established.
* Compiling `g77' requires GNU C, not just ANSI C. Fixing this
wouldn't be very hard (just tedious), but the code using GNU
extensions to the C language is expected to be rewritten for 0.6
anyway, so there are no plans for an interim fix.
File: ^.!gcc.docs.fortran.g77, Node: Cross-compiler Problems, Prev: General Problems, Up: Problems Installing
Cross-compiler Problems
-----------------------
`g77' has been in alpha testing since September of 1992, and in
public beta testing since February of 1995. Alpha testing was done by
a small number of people worldwide on a fairly wide variety of
machines, involving self-compilation in most or all cases. Beta
testing has been done primarily via self-compilation, but in more and
more cases, cross-compilation (and "criss-cross compilation", where a
version of a compiler is built on one machine to run on a second and
generate code that runs on a third) has been tried and has succeeded,
to varying extents.
Generally, `g77' can be ported to any configuration to which `gcc',
`f2c', and `libf2c' can be ported and made to work together, aside from
the known problems described in this manual. If you want to port `g77'
to a particular configuration, you should first make sure `gcc' and
`libf2c' can be ported to that configuration before focusing on `g77',
because `g77' is so dependent on them.
Even for cases where `gcc' and `libf2c' work, you might run into
problems with cross-compilation on certain machines, for several
reasons.
* There is one known bug (a design bug to be fixed in 0.6) that
prevents configuration of `g77' as a cross-compiler in some cases,
though there are assumptions made during configuration that
probably make doing non-self-hosting builds a hassle, requiring
manual intervention.
* `gcc' might still have some trouble being configured for certain
combinations of machines. For example, it might not know how to
handle floating-point constants.
* There are still some challenges putting together the right
run-time libraries (needed by `libf2c') for a target system,
depending on the systems involved in the configuration. (This is
a general problem with cross-compilation, and with `gcc' in
particular.)
File: ^.!gcc.docs.fortran.g77, Node: Quick Start, Next: Complete Installation, Prev: Problems Installing, Up: Installation
Quick Start
===========
This procedure configures, builds, and installs `g77' "out of the
box" and works on most UNIX systems. Each command is identified by a
unique number, used in the explanatory text that follows. For the most
part, the output of each command is not shown, though indications of
the types of responses are given in a few cases.
To perform this procedure, the installer must be logged in as user
`root'. Much of it can be done while not logged in as `root', and
users experienced with UNIX administration should be able to modify the
procedure properly to do so.
Following traditional UNIX conventions, it is assumed that the
source trees for `g77' and `gcc' will be placed in `/usr/src'. It also
is assumed that the source distributions themselves already reside in
`/usr/FSF', a naming convention used by the author of `g77' on his own
system:
/usr/FSF/gcc-2.7.2.tar.gz
/usr/FSF/g77-0.5.18.tar.gz
Users of the following systems should not blindly follow these
quick-start instructions, because of problems their systems have coping
with straightforward installation of `g77':
* SunOS
* Alpha
Instead, see *Note Complete Installation::, for detailed information
on how to configure, build, and install `g77' for your particular
system. Also, see *Note Known Causes of Trouble with GNU Fortran:
Trouble, for information on bugs and other problems known to afflict the
installation process, and how to report newly discovered ones.
If your system is *not* on the above list, and *is* a UNIX system or
one of its variants, you should be able to follow the instructions
below. If you vary *any* of the steps below, you might run into
trouble, including possibly breaking existing programs for other users
of your system. Before doing so, it is wise to review the explanations
of some of the steps. These explanations follow this list of steps.
sh[ 1]# `cd /usr/src'
sh[ 2]# `gunzip -c < /usr/FSF/gcc-2.7.2.tar.gz | tar xf -'
[Might say "Broken pipe"...that is normal on some systems.]
sh[ 3]# `gunzip -c < /usr/FSF/g77-0.5.18.tar.gz | tar xf -'
["Broken pipe" again possible.]
sh[ 4]# `ln -s gcc-2.7.2 gcc'
sh[ 5]# `ln -s g77-0.5.18 g77'
sh[ 6]# `mv -i g77/* gcc'
[No questions should be asked by mv here; or, you made a mistake.]
sh[ 7]# `patch -p1 -V t -d gcc-2.7.2 < gcc-2.7.2/f/gbe/2.7.2.diff'
[Unless patch complains about rejected patches, this step worked.]
sh[ 8]# `cd gcc'
sh[ 9]# `touch f77-install-ok'
[Do not do the above if your system already has an f77
command, unless you've checked that overwriting it
is okay.]
sh[10]# `touch f2c-install-ok'
[Do not do the above if your system already has an f2c
command, unless you've checked that overwriting it
is okay. Else, `touch f2c-exists-ok'.]
sh[11]# `./configure --prefix=/usr'
[Do not do the above if gcc is not installed in /usr/bin.
You might need a different `--prefix=...', as
described below.]
sh[12]# `make bootstrap'
[This takes a long time, and is where most problems occur.]
sh[13]# `rm -fr stage1'
sh[14]# `make -k install'
[The actual installation.]
sh[15]# `g77 -v'
[Verify that g77 is installed, obtain version info.]
sh[16]#
*Note Updating Your Info Directory: Updating Documentation, for
information on how to update your system's top-level `info' directory
to contain a reference to this manual, so that users of `g77' can
easily find documentation instead of having to ask you for it.
Elaborations of many of the above steps follows:
Step 1: `cd /usr/src'
You can build `g77' pretty much anyplace. By convention, this
manual assumes `/usr/src'. It might be helpful if other users on
your system knew where to look for the source code for the
installed version of `g77' and `gcc' in any case.
Step 4: `ln -s gcc-2.7.2 gcc'
Step 5: `ln -s g77-0.5.18 g77'
These commands mainly help reduce typing, and help reduce visual
clutter in examples in this manual showing what to type to install
`g77'.
*Note Unpacking::, for information on using distributions of `g77'
made by organizations other than the FSF.
Step 6: `mv -i g77/* gcc'
After doing this, you can, if you like, type `rm g77' and `rmdir
g77-0.5.18' to remove the empty directory and the symbol link to
it. But, it might be helpful to leave them around as quick
reminders of which version(s) of `g77' are installed on your
system.
*Note Unpacking::, for information on the contents of the `g77'
directory (as merged into the `gcc' directory).
Step 7: `patch -p1 ...'
This can produce a wide variety of printed output, from `Hmm, I
can't seem to find a patch in there anywhere...' to long lists of
messages indicated that patches are being found, applied
successfully, and so on.
If messages about "fuzz", "offset", or especially "reject files"
are printed, it might mean you applied the wrong patch file. If
you believe this is the case, it is best to restart the sequence
after deleting (or at least renaming to unused names) the
top-level directories for `g77' and `gcc' and their symbolic links.
After this command finishes, the `gcc' directory might have old
versions of several files as saved by `patch'. To remove these,
after `cd gcc', type `rm -i *.~*~'.
*Note Merging Distributions::, for more information.
Step 9: `touch f77-install-ok'
Don't do this if you don't want to overwrite an existing version
of `f77' (such as a native compiler, or a script that invokes
`f2c'). Otherwise, installation will overwrite the `f77' command
and the `f77' man pages with copies of the corresponding `g77'
material.
*Note Installing `f77': Installing f77, for more information.
Step 10: `touch f2c-install-ok'
Don't do this if you don't want to overwrite an existing
installation of `libf2c' (though, chances are, you do). Instead,
`touch f2c-exists-ok' to allow the installation to continue
without any error messages about `/usr/lib/libf2c.a' already
existing.
*Note Installing `f2c': Installing f2c, for more information.
Step 11: `./configure --prefix=/usr'
This is where you specify that the `g77' executable is to be
installed in `/usr/bin/', the `libf2c.a' library is to be
installed in `/usr/lib/', and so on.
You should ensure that any existing installation of the `gcc'
executable is in `/usr/bin/'. Otherwise, installing `g77' so that
it does not fully replace the existing installation of `gcc' is
likely to result in the inability to compile Fortran programs.
*Note Where in the World Does Fortran (and GNU C) Go?: Where to
Install, for more information on determining where to install
`g77'. *Note Configuring gcc::, for more information on the
configuration process triggered by invoking the `./configure'
script.
Step 12: `make bootstrap'
*Note Installing GNU CC: (gcc)Installation, for information on the
kinds of diagnostics you should expect during this procedure.
*Note Building gcc::, for complete `g77'-specific information on
this step.
Step 13: `rm -fr stage1'
You don't need to do this, but it frees up disk space.
Step 14: `make -k install'
If this doesn't seem to work, try:
make -k install install-libf77 install-f2c-all
*Note Installation of Binaries::, for more information.
*Note Updating Your Info Directory: Updating Documentation, for
information on entering this manual into your system's list of
texinfo manuals.
File: ^.!gcc.docs.fortran.g77, Node: Complete Installation, Next: Distributing Binaries, Prev: Quick Start, Up: Installation
Complete Installation
=====================
Here is the complete `g77'-specific information on how to configure,
build, and install `g77'.
* Menu:
* Unpacking::
* Merging Distributions::
* f77: Installing f77.
* f2c: Installing f2c.
* Patching GNU Fortran::
* Where to Install::
* Configuring gcc::
* Building gcc::
* Pre-installation Checks::
* Installation of Binaries::
* Updating Documentation::
* bison: Missing bison?.
* makeinfo: Missing makeinfo?.
File: ^.!gcc.docs.fortran.g77, Node: Unpacking, Next: Merging Distributions, Up: Complete Installation
Unpacking
---------
The `gcc' source distribution is a stand-alone distribution. It is
designed to be unpacked (producing the `gcc' source tree) and built as
is, assuming certain prerequisites are met (including the availability
of compatible UNIX programs such as `make', `cc', and so on).
However, before building `gcc', you will want to unpack and merge
the `g77' distribution in with it, so that you build a Fortran-capable
version of `gcc', which includes the `g77' command, the necessary
run-time libraries, and this manual.
Unlike `gcc', the `g77' source distribution is *not* a stand-alone
distribution. It is designed to be unpacked and, afterwards,
immediately merged into an applicable `gcc' source tree. That is, the
`g77' distribution *augments* a `gcc' distribution--without `gcc',
generally only the documentation is immediately usable.
A sequence of commands typically used to unpack `gcc' and `g77' is:
sh# `cd /usr/src'
sh# `gunzip -d < /usr/FSF/gcc-2.7.2.tar.gz | tar xf -'
sh# `gunzip -d < /usr/FSF/g77-0.5.18.tar.gz | tar xf -'
sh# `ln -s gcc-2.7.2 gcc'
sh# `ln -s g77-0.5.18 g77'
sh# `mv -i g77/* gcc'
*Notes:* The commands beginning with `gunzip...' might print `Broken
pipe...' as they complete. That is nothing to worry about, unless you
actually *hear* a pipe breaking. The `ln' commands are helpful in
reducing typing and clutter in installation examples in this manual.
Hereafter, the top level of `gcc' source tree is referred to as `gcc',
and the top level of just the `g77' source tree (prior to issuing the
`mv' command, above) is referred to as `g77'.
There are three top-level names in a `g77' distribution:
g77/COPYING.g77
g77/README.g77
g77/f
All three entries should be moved (or copied) into a `gcc' source
tree (typically named after its version number and as it appears in the
FSF distributions--e.g. `gcc-2.7.2').
`g77/f' is the subdirectory containing all of the code,
documentation, and other information that is specific to `g77'. The
other two files exist to provide information on `g77' to someone
encountering a `gcc' source tree with `g77' already present, who has
not yet read these installation instructions and thus needs help
understanding that the source tree they are looking at does not come
from a single FSF distribution. They also help people encountering an
unmerged `g77' source tree for the first time.
*Note:* Please use *only* `gcc' and `g77' source trees as
distributed by the FSF. Use of modified versions, such as the
Pentium-specific-optimization port of `gcc', is likely to result in
problems that appear to be in the `g77' code but, in fact, are not. Do
not use such modified versions unless you understand all the
differences between them and the versions the FSF distributes--in which
case you should be able to modify the `g77' (or `gcc') source trees
appropriately so `g77' and `gcc' can coexist as they do in the stock
FSF distributions.
File: ^.!gcc.docs.fortran.g77, Node: Merging Distributions, Next: Installing f77, Prev: Unpacking, Up: Complete Installation
Merging Distributions
---------------------
After merging the `g77' source tree into the `gcc' source tree, the
final merge step is done by applying the pertinent patches the `g77'
distribution provides for the `gcc' source tree.
Read the file `gcc/f/gbe/README', and apply the appropriate patch
file for the version of the GNU CC compiler you have, if that exists.
If the directory exists but the appropriate file does not exist, you
are using either an old, unsupported version, or a release one that is
newer than the newest `gcc' version supported by the version of `g77'
you have.
GNU version numbers make it easy to figure out whether a particular
version of a distribution is newer or older than some other version of
that distribution. The format is, generally, MAJOR.MINOR.PATCH, with
each field being a decimal number. (You can safely ignore leading
zeros; for example, 1.5.3 is the same as 1.5.03.) The MAJOR field only
increases with time. The other two fields are reset to 0 when the
field to their left is incremented; otherwise, they, too, only increase
with time. So, version 2.6.2 is newer than version 2.5.8, and version
3.0 is newer than both. (Trailing `.0' fields often are omitted in
announcements and in names for distributions and the directories they
create.)
If your version of `gcc' is older than the oldest version supported
by `g77' (as casually determined by listing the contents of
`gcc/f/gbe/'), you should obtain a newer, supported version of `gcc'.
(You could instead obtain an older version of `g77', or try and get
your `g77' to work with the old `gcc', but neither approach is
recommended, and you shouldn't bother reporting any bugs you find if you
take either approach, because they're probably already fixed in the
newer versions you're not using.)
If your version of `gcc' is newer than the newest version supported
by `g77', it is possible that your `g77' will work with it anyway. If
the version number for `gcc' differs only in the PATCH field, you might
as well try applying the `g77' patch that is for the newest version of
`gcc' having the same MAJOR and MINOR fields, as this is likely to work.
So, for example, if `g77' has support for versions 2.7.0 and 2.7.1,
it is likely that `gcc-2.7.2' would work well with `g77' by using the
`2.7.1.diff' patch file provided with `g77' (aside from some offsets
reported by `patch', which usually are harmless).
However, `gcc-2.8.0' would almost certainly not work with that
version of `g77' no matter which patch file was used, so a new version
of `g77' would be needed (and you should wait for it rather than
bothering the maintainers--*note User-Visible Changes: Changes.).
This complexity is the result of `gcc' and `g77' being separate
distributions. By keeping them separate, each product is able to be
independently improved and distributed to its user base more frequently.
However, `g77' often requires changes to contemporary versions of
`gcc'. Also, the GBE interface defined by `gcc' typically undergoes
some incompatible changes at least every time the MINOR field of the
version number is incremented, and such changes require corresponding
changes to the `g77' front end (FFE).
It is hoped that the GBE interface, and the `gcc' and `g77' products
in general, will stabilize sufficiently for the need for hand-patching
to disappear.
Invoking `patch' as described in `gcc/f/gbe/README' can produce a
wide variety of printed output, from `Hmm, I can't seem to find a patch
in there anywhere...' to long lists of messages indicated that patches
are being found, applied successfully, and so on.
If messages about "fuzz", "offset", or especially "reject files" are
printed, it might mean you applied the wrong patch file. If you
believe this is the case, it is best to restart the sequence after
deleting (or at least renaming to unused names) the top-level
directories for `g77' and `gcc' and their symbolic links. That is
because `patch' might have partially patched some `gcc' source files,
so reapplying the correct patch file might result in the correct
patches being applied incorrectly (due to the way `patch' necessarily
works).
After `patch' finishes, the `gcc' directory might have old versions
of several files as saved by `patch'. To remove these, after `cd gcc',
type `rm -i *.~*~'.
*Note:* `g77''s configuration file `gcc/f/config-lang.in' ensures
that the source code for the version of `gcc' being configured has at
least one GBE function required specifically by `g77'. This function
was added to `gcc-2.7.1', making the patch file
`g77-0.5.17/f/gbe/2.7.1.diff' empty of actual patches.
For `gcc-2.7.0' and earlier, this configuration-time checking should
catch failure to apply the correct patch and, if so caught, it should
abort the configuration with an explanation. *Please* do not try to
disable the check, otherwise `g77' might well appear to build and
install correctly, and even appear to compile correctly, but could
easily produce broken code.
`diff -rcp2N' is used to create the patch files in `gcc/f/gbe/'.
File: ^.!gcc.docs.fortran.g77, Node: Installing f77, Next: Installing f2c, Prev: Merging Distributions, Up: Complete Installation
Installing `f77'
----------------
You should decide whether you want installation of `g77' to also
install an `f77' command. On systems with a native `f77', this is not
normally desired, so `g77' does not do this by default.
If you want `f77' installed, create the file `f77-install-ok' (e.g.
via the UNIX command `touch f77-install-ok') in the source or build
top-level directory (the same directory in which the `g77' `f'
directory resides, not the `f' directory itself), or edit
`gcc/f/Make-lang.in' and change the definition of the
`F77_INSTALL_FLAG' macro appropriately.
Usually, this means that, after typing `cd gcc', you would type
`touch f77-install-ok'.
When you enable installation of `f77', either a link to or a direct
copy of the `g77' command is made. Similarly, `f77.1' is installed as
a man page.
(The `uninstall' target in the `gcc/Makefile' also tests this macro
and file, when invoked, to determine whether to delete the installed
copies of `f77' and `f77.1'.)
*Note:* No attempt is yet made to install a program (like a shell
script) that provides compatibility with any other `f77' programs.
Only the most rudimentary invocations of `f77' will work the same way
with `g77'.
File: ^.!gcc.docs.fortran.g77, Node: Installing f2c, Next: Patching GNU Fortran, Prev: Installing f77, Up: Complete Installation
Installing `f2c'
----------------
Currently, `g77' does not include `f2c' itself in its distribution.
However, it does include a modified version of the `libf2c'. This
version is normally compatible with `f2c', but has been modified to
meet the needs of `g77' in ways that might possibly be incompatible
with some versions or configurations of `f2c'.
Decide how installation of `g77' should affect any existing
installation of `f2c' on your system.
If you do not have `f2c' on your system (e.g. no `/usr/bin/f2c', no
`/usr/include/f2c.h', and no `/usr/lib/libf2c.a', `/usr/lib/libF77.a',
or `/usr/lib/libI77.a'), you don't need to be concerned with this item.
If you do have `f2c' on your system, you need to decide how users of
`f2c' will be affected by your installing `g77'. Since `g77' is
currently designed to be object-code-compatible with `f2c' (with very
few, clear exceptions), users of `f2c' might want to combine
`f2c'-compiled object files with `g77'-compiled object files in a
single executable.
To do this, users of `f2c' should use the same copies of `f2c.h' and
`libf2c.a' that `g77' uses (and that get built as part of `g77').
If you do nothing here, the `g77' installation process will not
overwrite the `include/f2c.h' and `lib/libf2c.a' files with its own
versions, and in fact will not even install `libf2c.a' for use with the
newly installed versions of `gcc' and `g77' if it sees that
`lib/libf2c.a' exists--instead, it will print an explanatory message
and skip this part of the installation.
To install `g77''s versions of `f2c.h' and `libf2c.a' in the
appropriate places, create the file `f2c-install-ok' (e.g. via the UNIX
command `touch f2c-install-ok') in the source or build top-level
directory (the same directory in which the `g77' `f' directory resides,
not the `f' directory itself), or edit `gcc/f/Make-lang.in' and change
the definition of the `F2C_INSTALL_FLAG' macro appropriately.
Usually, this means that, after typing `cd gcc', you would type
`touch f2c-install-ok'.
Make sure that when you enable the overwriting of `f2c.h' and
`libf2c.a' as used by `f2c', you have a recent and properly configured
version of `bin/f2c' so that it generates code that is compatible with
`g77'.
If you don't want installation of `g77' to overwrite `f2c''s existing
installation, but you do want `g77' installation to proceed with
installation of its own versions of `f2c.h' and `libf2c.a' in places
where `g77' will pick them up (even when linking `f2c'-compiled object
files--which might lead to incompatibilities), create the file
`f2c-exists-ok' (e.g. via the UNIX command `touch f2c-exists-ok') in
the source or build top-level directory, or edit `gcc/f/Make-lang.in'
and change the definition of the `F2CLIBOK' macro appropriately.
File: ^.!gcc.docs.fortran.g77, Node: Patching GNU Fortran, Next: Where to Install, Prev: Installing f2c, Up: Complete Installation
Patching GNU Fortran
--------------------
If you're using a SunOS system, you'll need to make the following
change to `gcc/f/proj.h': edit the line reading
#define FFEPROJ_STRTOUL 1 ...
by replacing the `1' with `0'.
This causes a minimal version of `strtoul()' provided as part of the
`g77' distribution to be compiled and linked into whatever `g77'
programs need it, since some systems (like SunOS) do not provide this
function in their system libraries.
Similarly, a minimal version of `bsearch()' is available and can be
enabled by editing a line similar to the one for `strtoul()' above in
`gcc/f/proj.h', if your system libraries lack `bsearch()'.
These are not problems with `g77', which requires an ANSI C
environment. You should upgrade your system to one that provides a
full ANSI C environment, or encourage the maintainers of `gcc' to
provide one to all `gcc'-based compilers in future `gcc' distributions.
*Note Problems Installing::, for more information on why `strtoul()'
comes up missing and on approaches to dealing with this problem that
have already been tried.
File: ^.!gcc.docs.fortran.g77, Node: Where to Install, Next: Configuring gcc, Prev: Patching GNU Fortran, Up: Complete Installation
Where in the World Does Fortran (and GNU C) Go?
-----------------------------------------------
Before configuring, you should make sure you know where you want the
`g77' and `gcc' binaries to be installed after they're built, because
this information is given to the configuration tool and used during the
build itself.
A `g77' installation necessarily requires installation of a
`g77'-aware version of `gcc', so that the `gcc' command recognizes
Fortran source files and knows how to compile them.
For this to work, the version of `gcc' that you will be building as
part of `g77' *must* be installed as the "active" version of `gcc' on
the system.
Sometimes people make the mistake of installing `gcc' as
`/usr/local/bin/gcc', leaving an older, non-Fortran-aware version in
`/usr/bin/gcc'. (Or, the opposite happens.) This can result in `g77'
being unable to compile Fortran source files, because when it calls on
`gcc' to do the actual compilation, `gcc' complains that it does not
recognize the language, or the file name suffix.
So, determine whether `gcc' already is installed on your system,
and, if so, *where* it is installed, and prepare to configure the new
version of `gcc' you'll be building so that it installs over the
existing version of `gcc'.
You might want to back up your existing copy of `bin/gcc', and the
entire `lib/' directory, before you perform the actual installation (as
described in this manual).
Existing `gcc' installations typically are found in `/usr' or
`/usr/local'. If you aren't certain where the currently installed
version of `gcc' and its related programs reside, look at the output of
this command:
gcc -v -o /tmp/delete-me -xc /dev/null -xnone
All sorts of interesting information on the locations of various
`gcc'-related programs and data files should be visible in the output
of the above command. However, you do have to sift through it
yourself; `gcc' currently provides no easy way to ask it where it is
installed and where it looks for the various programs and data files it
calls on to do its work.
Just *building* `g77' should not overwrite any installed
programs--but, usually, after you build `g77', you will want to install
it, so backing up anything it might overwrite is a good idea. (This is
true for any package, not just `g77', though in this case it is
intentional that `g77' overwrites `gcc' if it is already installed--it
is unusual that the installation process for one distribution
intentionally overwrites a program or file installed by another
distribution.)
Another reason to back up the existing version first, or make sure
you can restore it easily, is that it might be an older version on
which other users have come to depend for certain behaviors. However,
even the new version of `gcc' you install will offer users the ability
to specify an older version of the actual compilation programs if
desired, and these older versions need not include any `g77' components.
*Note Specifying Target Machine and Compiler Version: (gcc)Target
Options, for information on the `-V' option of `gcc'.
File: ^.!gcc.docs.fortran.g77, Node: Configuring gcc, Next: Building gcc, Prev: Where to Install, Up: Complete Installation
Configuring GNU CC
------------------
`g77' is configured automatically when you configure `gcc'. There
are two parts of `g77' that are configured in two different
ways--`g77', which "camps on" to the `gcc' configuration mechanism, and
`libf2c', which uses a variation of the GNU `autoconf' configuration
system.
Generally, you shouldn't have to be concerned with either `g77' or
`libf2c' configuration, unless you're configuring `g77' as a
cross-compiler. In this case, the `libf2c' configuration, and possibly
the `g77' and `gcc' configurations as well, might need special
attention. (This also might be the case if you're porting `gcc' to a
whole new system--even if it is just a new operating system on an
existing, supported CPU.)
To configure the system, see *Note Installing GNU CC:
(gcc)Installation, following the instructions for running `./configure'.
Pay special attention to the `--prefix=' option, which you almost
certainly will need to specify.
(Note that `gcc' installation information is provided as a straight
text file in `gcc/INSTALL'.)
The information printed by the invocation of `./configure' should
show that the `f' directory (the Fortran language) has been configured.
If it does not, there is a problem.
*Note:* Configuring with the `--srcdir' argument is known to work
with GNU `make', but it is not known to work with other variants of
`make'. Irix5.2 and SunOS4.1 versions of `make' definitely won't work
outside the source directory at present. `g77''s portion of the
`configure' script issues a warning message about this when you
configure for building binaries outside the source directory.
File: ^.!gcc.docs.fortran.g77, Node: Building gcc, Next: Pre-installation Checks, Prev: Configuring gcc, Up: Complete Installation
Building GNU CC
---------------
Building `g77' requires building enough of `gcc' that these
instructions assume you're going to build all of `gcc', including
`g++', `protoize', and so on. You can save a little time and disk
space by changes the `LANGUAGES' macro definition in `gcc/Makefile.in'
or `gcc/Makefile', but if you do that, you're on your own. One change
is almost *certainly* going to cause failures: removing `c' or `f77'
from the definition of the `LANGUAGES' macro.
After configuring `gcc', which configures `g77' and `libf2c'
automatically, you're ready to start the actual build by invoking
`make'.
*Note:* You *must* have run `./configure' before you run `make',
even if you're using an already existing `gcc' development directory,
because `./configure' does the work to recognize that you've added
`g77' to the configuration.
There are two general approaches to building GNU CC from scratch:
"bootstrap"
This method uses minimal native system facilities to build a
barebones, unoptimized `gcc', that is then used to compile
("bootstrap") the entire system.
"straight"
This method assumes a more complete native system exists, and uses
that just once to build the entire system.
On all systems without a recent version of `gcc' already installed,
the bootstrap method must be used. In particular, `g77' uses
extensions to the C language offered, apparently, only by `gcc'.
On most systems with a recent version of `gcc' already installed,
the straight method can be used. This is an advantage, because it
takes less CPU time and disk space for the build. However, it does
require that the system have fairly recent versions of many GNU
programs and other programs, which are not enumerated here.
* Menu:
* Bootstrap Build:: For all systems.
* Straight Build:: For systems with a recent version of `gcc'.
File: ^.!gcc.docs.fortran.g77, Node: Bootstrap Build, Next: Straight Build, Up: Building gcc
Bootstrap Build
...............
A complete bootstrap build is done by issuing a command beginning
with `make bootstrap ...', as described in *Note Installing GNU CC:
(gcc)Installation. This is the most reliable form of build, but it
does require the most disk space and CPU time, since the complete system
is built twice (in Stages 2 and 3), after an initial build (during
Stage 1) of a minimal `gcc' compiler using the native compiler and
libraries.
You might have to, or want to, control the way a bootstrap build is
done by entering the `make' commands to build each stage one at a time,
as described in the `gcc' manual. For example, to save time or disk
space, you might want to not bother doing the Stage 3 build, in which
case you are assuming that the `gcc' compiler you have built is
basically sound (because you are giving up the opportunity to compare a
large number of object files to ensure they're identical).
To save some disk space during installation, after Stage 2 is built,
you can type `rm -fr stage1' to remove the binaries built during Stage
*Note:* If you do build Stage 3 and you compare the object files
produced by various stages, the file `gcc/f/zzz.o' *will* be different.
That is because it contains a string with an expansion of the
`__TIME__' macro, which expands to the current time of day. It is
nothing to worry about, since `gcc/f/zzz.c' doesn't contain any actual
code. It does allow you to override its use of `__DATE__' and
`__TIME__' by defining macros for the compilation--see the source code
for details.
*Note Installing GNU CC: (gcc)Installation, for important
information on building `gcc' that is not described in this `g77'
manual. For example, explanations of diagnostic messages and whether
they're expected, or indicate trouble, are found there.
File: ^.!gcc.docs.fortran.g77, Node: Straight Build, Prev: Bootstrap Build, Up: Building gcc
Straight Build
..............
If you have a recent version of `gcc' already installed on your
system, and if you're reasonably certain it produces code that is
object-compatible with the version of `gcc' you want to build as part
of building `g77', you can save time and disk space by doing a straight
build.
To build just the C and Fortran compilers and the necessary run-time
libraries, issue the following command:
make -k CC=gcc LANGUAGES=f77 all g77
(The `g77' target is necessary because the `gcc' build procedures
apparently do not automatically build command drivers for languages in
subdirectories. It's the `all' target that triggers building
everything except, apparently, the `g77' command itself.)
If you run into problems using this method, you have two options:
* Abandon this approach and do a bootstrap build.
* Try to make this approach work by diagnosing the problems you're
running into and retrying.
Especially if you do the latter, you might consider submitting any
solutions as bug/fix reports. *Note Known Causes of Trouble with GNU
Fortran: Trouble.
However, understand that many problems preventing a straight build
from working are not `g77' problems, and, in such cases, are not likely
to be addressed in future versions of `g77'.
File: ^.!gcc.docs.fortran.g77, Node: Pre-installation Checks, Next: Installation of Binaries, Prev: Building gcc, Up: Complete Installation
Pre-installation Checks
-----------------------
Before installing the system, which includes installing `gcc', you
might want to do some minimum checking to ensure that some basic things
work.
Here are some commands you can try, and output typically printed by
them when they work:
sh# `cd /usr/src/gcc'
sh# `./g77 --driver=./xgcc -B./ -v'
./xgcc -B./ -v -fnull-version -o /tmp/gfa03648 ...
Reading specs from ./specs
gcc version 2.7.1
./cpp -lang-c -v -isystem ./include -undef ...
GNU CPP version 2.7.1 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
./include
/usr/include
/usr/i486-unknown-linuxaout/include
/usr/lib/gcc-lib/i486-unknown-linuxaout/2.7.1/include
/usr/include
End of search list.
./f771 /tmp/cca03648.i -quiet -dumpbase null.F -version ...
GNU F77 version 2.7.1 (80386, BSD syntax) compiled ...
GNU Fortran Front End version 0.5.18 compiled: ...
as -o /tmp/cca036481.o /tmp/cca03648.s
ld -m i386linux -o /tmp/gfa03648 /usr/lib/crt0.o -L. ...
/usr/lib/crt0.o(.text+0x35): undefined reference to `main'
sh# `./xgcc -B./ -v -o /tmp/delete-me -xc /dev/null -xnone'
Reading specs from ./specs
gcc version 2.7.1
./cpp -lang-c -v -isystem ./include -undef ...
GNU CPP version 2.7.1 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
./include
/usr/include
/usr/i486-unknown-linuxaout/include
/usr/lib/gcc-lib/i486-unknown-linuxaout/2.7.1/include
/usr/include
End of search list.
./cc1 /tmp/cca03659.i -quiet -dumpbase null.c -version ...
GNU C version 2.7.1 (80386, BSD syntax) compiled ...
as -o /tmp/cca036591.o /tmp/cca03659.s
ld -m i386linux -o /tmp/delete-me /usr/lib/crt0.o -L. ...
/usr/lib/crt0.o(.text+0x35): undefined reference to `main'
sh#
(Note that long lines have been truncated, and `...' used to
indicate such truncations.)
The above two commands test whether `g77' and `gcc', respectively,
are able to compile empty (null) source files, whether invocation of
the C preprocessor works, whether libraries can be linked (even though
there is an undefined reference due to there being no main program
unit), and so on.
If the output you get from either of the above two commands is
noticably different, especially if it is shorter or longer in ways that
do not look consistent with the above sample output, you probably
should not install `gcc' and `g77' until you have investigated further.
For example, you could try compiling actual applications and seeing
how that works. (You might want to do that anyway, even if the above
tests work.)
To compile using the not-yet-installed versions of `gcc' and `g77',
use the following commands to invoke them.
To invoke `g77', type:
/usr/src/gcc/g77 --driver=/usr/src/gcc/xgcc -B/usr/src/gcc/ ...
To invoke `gcc', type:
/usr/src/gcc/xgcc -B/usr/src/gcc/ ...
File: ^.!gcc.docs.fortran.g77, Node: Installation of Binaries, Next: Updating Documentation, Prev: Pre-installation Checks, Up: Complete Installation
Installation of Binaries
------------------------
After configuring, building, and testing `g77' and `gcc', when you
are ready to install them on your system, type:
make -k CC=gcc LANGUAGES=f77 install
As described in *Note Installing GNU CC: (gcc)Installation, the
values for the `CC' and `LANGUAGES' macros should be the same as those
you supplied for the build itself.
So, the details of the above command might vary if you used a
bootstrap build (where you might be able to omit both definitions, or
might have to supply the same definitions you used when building the
final stage) or if you deviated from the instructions for a straight
build.
If the above command does not install `libf2c.a' as expected, try
this:
make -k ... install install-libf77 install-f2c-all
We don't know why some non-GNU versions of `make' sometimes require
this alternate command, but they do. (Remember to supply the
appropriate definitions for `CC' and `LANGUAGES' where you see `...' in
the above command.)
Note that using the `-k' option tells `make' to continue after some
installation problems, like not having `makeinfo' installed on your
system. It might not be necessary.
File: ^.!gcc.docs.fortran.g77, Node: Updating Documentation, Next: Missing bison?, Prev: Installation of Binaries, Up: Complete Installation
Updating Your Info Directory
----------------------------
As part of installing `g77', you should make sure users of `info'
can easily access this manual on-line. Do this by making sure a line
such as the following exists in `/usr/info/dir', or in whatever file is
the top-level file in the `info' directory on your system (perhaps
`/usr/local/info/dir':
* g77: (g77). The GNU Fortran programming language.
If the menu in `dir' is organized into sections, `g77' probably
belongs in a section with a name such as the following:
* Writing Programs
* Programming Languages
* Languages Other Than C
* Scientific/Engineering Tools
* GNU Compilers
File: ^.!gcc.docs.fortran.g77, Node: Missing bison?, Next: Missing makeinfo?, Prev: Updating Documentation, Up: Complete Installation
Missing `bison'?
----------------
If you cannot install `bison', make sure you have started with a
*fresh* distribution of `gcc', do *not* do `make maintainer-clean' (in
other versions of `gcc', this was called `make realclean'), and, to
ensure that `bison' is not invoked by `make' during the build, type
these commands:
sh# `cd gcc'
sh# `touch bi-parser.c bi-parser.h c-parse.c c-parse.h cexp.c'
sh# `touch cp/parse.c cp/parse.h objc-parse.c'
sh#
These commands update the date-time-modified information for all the
files produced by the various invocations of `bison' in the current
versions of `gcc', so that `make' no longer believes it needs to update
them. All of these files should already exist in a `gcc' distribution,
but the application of patches to upgrade to a newer version can leave
the modification information set such that the `bison' input files look
more "recent" than the corresponding output files.
*Note:* New versions of `gcc' might change the set of files it
generates by invoking `bison'--if you cannot figure out for yourself
how to handle such a situation, try an older version of `gcc' until you
find someone who can (or until you obtain and install `bison').
File: ^.!gcc.docs.fortran.g77, Node: Missing makeinfo?, Prev: Missing bison?, Up: Complete Installation
Missing `makeinfo'?
-------------------
If you cannot install `makeinfo', either use the `-k' option when
invoking make to specify any of the `install' or related targets, or
specify `MAKEINFO=echo' on the `make' command line.
If you fail to do one of these things, some files, like `libf2c.a',
might not be installed, because the failed attempt by `make' to invoke
`makeinfo' causes it to cancel any further processing.
File: ^.!gcc.docs.fortran.g77, Node: Distributing Binaries, Next: Settings, Prev: Complete Installation, Up: Installation
Distributing Binaries
=====================
If you are building `g77' for distribution to others in binary form,
first make sure you are aware of your legal responsibilities (read the
file `gcc/COPYING' thoroughly).
Then, consider your target audience and decide where `g77' should be
installed.
For systems like Linux that have no native Fortran compiler (or
where `g77' could be considered the native compiler for Fortran and
`gcc' for C, etc.), you should definitely configure `g77' for
installation in `/usr/bin' instead of `/usr/local/bin'. Specify the
`--prefix=/usr' option when running `./configure'. You might also want
to set up the distribution so the `f77' command is a link to
`g77'--just make an empty file named `f77-install-ok' in the source or
build directory (the one in which the `f' directory resides, not the
`f' directory itself) when you specify one of the `install' or
`uninstall' targets in a `make' command.
For a system that might already have `f2c' installed, you definitely
will want to make another empty file (in the same directory) named
either `f2c-exists-ok' or `f2c-install-ok'. Use the former if you
don't want your distribution to overwrite `f2c'-related files in
existing systems; use the latter if you want to improve the likelihood
that users will be able to use both `f2c' and `g77' to compile code for
a single program without encountering link-time or run-time
incompatibilities.
(Make sure you clearly document, in the "advertising" for your
distribution, how installation of your distribution will affect
existing installations of `gcc', `f2c', `f77', `libf2c.a', and so on.
Similarly, you should clearly document any requirements you assume are
met by users of your distribution.)
For other systems with native `f77' (and `cc') compilers, configure
`g77' as you (or most of your audience) would configure `gcc' for their
installations. Typically this is for installation in `/usr/local', and
would not include a copy of `g77' named `f77', so users could still use
the native `f77'.
In any case, for `g77' to work properly, you *must* ensure that the
binaries you distribute include:
`bin/g77'
This is the command most users use to compile Fortran.
`bin/gcc'
This is the command all users use to compile Fortran, either
directly or indirectly via the `g77' command. The `bin/gcc'
executable file must have been built from a `gcc' source tree into
which a `g77' source tree was merged and configured, or it will
not know how to compile Fortran programs.
`bin/f77'
In installations with no non-GNU native Fortran compiler, this is
the same as `bin/g77'. Otherwise, it should be omitted from the
distribution, so the one on already on a particular system does
not get overwritten.
`info/g77.info*'
This is the documentation for `g77'.
Please edit this documentation (by editing `gcc/f/*.texi' and
doing `make doc' from the `/usr/src/gcc' directory) to reflect any
changes you've made to `g77', or at least to encourage users of
your binary distribution to report bugs to you first.
Also, whether you distribute binaries or install `g77' on your own
system, it might be helpful for everyone to add a line listing
this manual by name and topic to the top-level `info' node in
`/usr/info/dir'. That way, users can find `g77' documentation more
easily. *Note Updating Your Info Directory: Updating
Documentation.
`man/man1/g77.1'
This is the short man page for `g77'.
`man/man1/f77.1'
In installations where `f77' is the same as `g77', this is the
same as `man/man1/g77.1'. Otherwise, it should be omitted from
the distribution, so the one already on a particular system does
not get overwritten.
`lib/gcc-lib/.../f771'
This is the actual Fortran compiler.
`lib/gcc-lib/.../libf2c.a'
This is the run-time library for `g77'-compiled programs.
Whether you want to include the slightly updated (and possibly
improved) versions of `cc1', `cc1plus', and whatever other binaries get
rebuilt with the changes the GNU Fortran distribution makes to the GNU
back end, is up to you. These changes are highly unlikely to break any
compilers, and it is possible they'll fix back-end bugs that can be
demonstrated using front ends other than GNU Fortran's.
Please assure users that unless they have a specific need for their
existing, older versions of `gcc' command, they are unlikely to
experience any problems by overwriting it with your version--though
they could certainly protect themselves by making backup copies first!
Otherwise, users might try and install your binaries in a "safe" place,
find they cannot compile Fortran programs with your distribution
(because, perhaps, they're picking up their old version of the `gcc'
command, which does not recognize Fortran programs), and assume that
your binaries (or, more generally, GNU Fortran distributions in
general) are broken, at least for their system.
Finally, *please* ask for bug reports to go to you first, at least
until you're sure your distribution is widely used and has been well
tested. This especially goes for those of you making any changes to
the `g77' sources to port `g77', e.g. to OS/2.
`fortran@gnu.ai.mit.edu' has received a fair amount of bug reports that
turned out to be problems with other peoples' ports and distributions,
about which nothing could be done for the user. Once you are quite
certain a bug report does not involve your efforts, you can forward it
to us.
File: ^.!gcc.docs.fortran.g77, Node: Settings, Prev: Distributing Binaries, Up: Installation
Changing Settings Before Building
=================================
Here are some internal `g77' settings that can be changed by editing
source files in `gcc/f/' before building.
This information, and perhaps even these settings, represent
stop-gap solutions to problems people doing various ports of `g77' have
encountered. As such, none of the following information is expected to
be pertinent in future versions of `g77'.
* Menu:
* Maximum Stackable Size:: Large arrays are forced off the stack frame.
* Floating-point Bit Patterns:: Possible programs building cross-compiler.
* Large Initialization:: Large arrays with `DATA' initialization.
* Alpha Problems:: Problems with 64-bit systems like Alphas.
File: ^.!gcc.docs.fortran.g77, Node: Maximum Stackable Size, Next: Floating-point Bit Patterns, Up: Settings
Maximum Stackable Size
----------------------
`g77', on most machines, puts many variables and arrays on the stack
where possible, and can be configured (by changing
`FFECOM_sizeMAXSTACKITEM' in `gcc/f/com.c') to force smaller-sized
entities into static storage (saving on stack space) or permit
larger-sized entities to be put on the stack (which can improve
run-time performance, as it presents more opportunities for the GBE to
optimize the generated code).
File: ^.!gcc.docs.fortran.g77, Node: Floating-point Bit Patterns, Next: Large Initialization, Prev: Maximum Stackable Size, Up: Settings
Floating-point Bit Patterns
---------------------------
The `g77' build will crash if an attempt is made to build it as a
cross-compiler for a target when `g77' cannot reliably determine the
bit pattern of floating-point constants for the target. Planned
improvements for g77-0.6 will give it the capabilities it needs to not
have to crash the build but rather generate correct code for the target.
(Currently, `g77' would generate bad code under such circumstances if
it didn't crash during the build, e.g. when compiling a source file
that does something like `EQUIVALENCE (I,R)' and `DATA
R/3.1415926535/'.)
File: ^.!gcc.docs.fortran.g77, Node: Large Initialization, Next: Alpha Problems, Prev: Floating-point Bit Patterns, Up: Settings
Initialization of Large Aggregate Areas
---------------------------------------
A warning message is issued when `g77' sees code that provides
initial values (e.g. via `DATA') to an aggregate area (`COMMON' or
`EQUIVALENCE', or even a large enough array or `CHARACTER' variable)
that is large enough to increase `g77''s compile time by roughly a
factor of 10.
This size currently is quite small, since `g77' currently has a
known bug requiring too much memory and time to handle such cases. In
`gcc/f/data.c', the macro `FFEDATA_sizeTOO_BIG_INIT_' is defined to the
minimum size for the warning to appear. The size is specified in
storage units, which can be bytes, words, or whatever, on a
case-by-case basis.
After changing this macro definition, you must (of course) rebuild
and reinstall `g77' for the change to take effect.
Note that, as of version 0.5.18, improvements have reduced the scope
of the problem for *sparse* initialization of large arrays, especially
those with large, contiguous uninitialized areas. However, the warning
is issued at a point prior to when `g77' knows whether the
initialization is sparse, and delaying the warning could mean it is
produced too late to be helpful.
Therefore, the macro definition should not be adjusted to reflect
sparse cases. Instead, adjust it to generate the warning when densely
initialized arrays begin to cause responses noticably slower than
linear performance would suggest.
File: ^.!gcc.docs.fortran.g77, Node: Alpha Problems, Prev: Large Initialization, Up: Settings
Alpha Problems
--------------
`g77' might warn when it is used to compile Fortran code for a
target configuration that is not basically a 32-bit machine (such as an
Alpha, which is a 64-bit machine, especially if it has a 64-bit
operating system running on it). This is because `g77' is known to not
work properly on such configurations, although the reasons for this are
not fully explored. This is expected to be fixed at 0.6, at which
point the warning would be dropped. (The reason the unexplored
problems are expected to be fixed at 0.6 is because some known internal
design problems `g77' has, which reduce portability and the ability to
configure it as a cross-compiler, are presumed to be at least partly
responsible for the problems being encountered on the Alpha. The
problems remain unexplored partly because the known problems exist and
are scheduled to be addressed anyway. Plus, the `g77' maintainer does
not yet possess an Alpha workstation of his own.)
File: ^.!gcc.docs.fortran.g77, Node: Debugging and Interfacing, Next: Collected Fortran Wisdom, Prev: Installation, Up: Top
Debugging and Interfacing
*************************
GNU Fortran currently generates code that is object-compatible with
the `f2c' converter. Also, it avoids limitations in the current GBE,
such as the inability to generate a procedure with multiple entry
points, by generating code that is structured differently (in terms of
procedure names, scopes, arguments, and so on) than might be expected.
As a result, writing code in other languages that calls on, is
called by, or shares in-memory data with `g77'-compiled code generally
requires some understanding of the way `g77' compiles code for various
constructs.
Similarly, using a debugger to debug `g77'-compiled code, even if
that debugger supports native Fortran debugging, generally requires
this sort of information.
This section describes some of the basic information on how `g77'
compiles code for constructs involving interfaces to other languages
and to debuggers.
*Caution:* Much or all of this information pertains to only the
current release of `g77', sometimes even to using certain compiler
options with `g77' (such as `-fno-f2c'). Do not write code that
depends on this information without clearly marking said code as
nonportable and subject to review for every new release of `g77'. This
information is provided primarily to make debugging of code generated
by this particular release of `g77' easier for the user, and partly to
make writing (generally nonportable) interface code easier. Both of
these activities require tracking changes in new version of `g77' as
they are installed, because new versions can change the behaviors
described in this section.
* Menu:
* Names:: Naming of user-defined variables, procedures, etc.
* Main Program Unit:: How `g77' compiles a main program unit.
* Arrays:: Dealing with (possibly multi-dimensional) arrays.
* Procedures:: How `g77' constructs parameter lists
for procedures.
* Adjustable Arrays:: Special consideration for adjustable arrays.
* Alternate Returns:: How `g77' handles alternate returns.
* Functions:: Functions returning floating-point or character data.
* Common Blocks:: Accessing common variables while debugging.
* Local Equivalence Areas:: Accessing `EQUIVALENCE' while debugging.
* Alternate Entry Points:: How `g77' implements alternate `ENTRY'.
* Assigned Statement Labels:: How `g77' handles `ASSIGN'.
File: ^.!gcc.docs.fortran.g77, Node: Names, Next: Main Program Unit, Up: Debugging and Interfacing
Names
=====
Fortran permits each implementation to decide how to represent names
as far as how they're seen in other contexts, such as debuggers and
when interfacing to other languages, and especially as far as how
casing is handled.
External names--names of entities that are public, or "accessible",
to all modules in a program--normally have an underscore (`_') appended
by `g77', to generate code that is compatible with f2c. External names
include names of Fortran things like common blocks, external procedures
(subroutines and functions, but not including statement functions,
which are internal procedures), and entry point names.
However, use of the `-fno-underscoring' option disables this kind of
transformation of external names (though inhibiting the transformation
certainly improves the chances of colliding with incompatible externals
written in other languages--but that might be intentional.
When `-funderscoring' is in force, any name (external or local) that
already has at least one underscore in it is implemented by `g77' by
appending two underscores. External names are changed this way for
`f2c' compatibility. Local names are changed this way to avoid
collisions with external names that are different in the source
code--`f2c' does the same thing, but there's no compatibility issue
there except for user expectations while debugging.
For example:
Max_Cost = 0
Here, a user would, in the debugger, refer to this variable using the
name `max_cost__' (or `MAX_COST__' or `Max_Cost__', as described below).
(We hope to improve `g77' in this regard in the future--don't write
scripts depending on this behavior! Also, consider experimenting with
the `-fno-underscoring' option to try out debugging without having to
massage names by hand like this.)
`g77' provides a number of command-line options that allow the user
to control how case mapping is handled for source files. The default
is the traditional UNIX model for Fortran compilers--names are mapped
to lower case. Other command-line options can be specified to map
names to upper case, or to leave them exactly as written in the source
file.
For example:
Foo = 3.14159
Here, it is normally the case that the variable assigned will be named
`foo'. This would be the name to enter when using a debugger to access
the variable.
However, depending on the command-line options specified, the name
implemented by `g77' might instead be `FOO' or even `Foo', thus
affecting how debugging is done.
Also:
Call Foo
This would normally call a procedure that, if it were in a separate C
program, be defined starting with the line:
void foo_()
However, `g77' command-line options could be used to change the casing
of names, resulting in the name `FOO_' or `Foo_' being given to the
procedure instead of `foo_', and the `-fno-underscoring' option could
be used to inhibit the appending of the underscore to the name.
File: ^.!gcc.docs.fortran.g77, Node: Main Program Unit, Next: Arrays, Prev: Names, Up: Debugging and Interfacing
Main Program Unit (PROGRAM)
===========================
When `g77' compiles a main program unit, it gives it the public
procedure name `MAIN__'. The `libf2c' library has the actual `main()'
procedure as is typical of C-based environments, and it is this
procedure that performs some initial start-up activity and then calls
`MAIN__'.
Generally, `g77' and `libf2c' are designed so that you need not
include a main program unit written in Fortran in your program--it can
be written in C or some other language. Especially for I/O handling,
this is the case, although `g77-0.5.16' includes a bug fix for `libf2c'
that solved a problem with using the `OPEN' statement as the first
Fortran I/O activity in a program without a Fortran main program unit.
However, if you don't intend to use `g77' (or `f2c') to compile your
main program unit--that is, if you intend to compile a `main()'
procedure using some other language--you should carefully examine the
code for `main()' in `libf2c', found in the source file
`gcc/f/runtime/libF77/main.c', to see what kinds of things might need
to be done by your `main()' in order to provide the Fortran environment
your Fortran code is expecting.
For example, `libf2c''s `main()' sets up the information used by the
`IARGC' and `GETARG' intrinsics. Bypassing `libf2c''s `main()' without
providing a substitute for this activity would mean that invoking
`IARGC' and `GETARG' would produce undefined results.
When debugging, one implication of the fact that `main()', which is
the place where the debugged program "starts" from the debugger's point
of view, is in `libf2c' is that you won't be starting your Fortran
program at a point you recognize as your Fortran code.
The standard way to get around this problem is to set a break point
(a one-time, or temporary, break point will do) at the entrance to
`MAIN__', and then run the program.
After doing this, the debugger will see the current execution point
of the program as at the beginning of the main program unit of your
program.
Of course, if you really want to set a break point at some other
place in your program and just start the program running, without first
breaking at `MAIN__', that should work fine.
File: ^.!gcc.docs.fortran.g77, Node: Arrays, Next: Procedures, Prev: Main Program Unit, Up: Debugging and Interfacing
Arrays (DIMENSION)
==================
Fortran uses "column-major ordering" in its arrays. This differs
from other languages, such as C, which use "row-major ordering". The
difference is that, with Fortran, array elements adjacent to each other
in memory differ in the *first* subscript instead of the last;
`A(5,10,20)' immediately follows `A(4,10,20)', whereas with row-major
ordering it would follow `A(5,10,19)'.
This consideration affects not only interfacing with and debugging
Fortran code, it can greatly affect how code is designed and written,
especially when code speed and size is a concern.
Fortran also differs from C, a popular language for interfacing and
to support directly in debuggers, in the way arrays are treated. In C,
arrays are single-dimensional and have interesting relationships to
pointers, neither of which is true for Fortran. As a result, dealing
with Fortran arrays from within an environment limited to C concepts
can be challenging.
For example, accessing the array element `A(5,10,20)' is easy enough
in Fortran (use `A(5,10,20)'), but in C some difficult machinations are
needed. First, C would treat the A array as a single-dimension array.
Second, C does not understand low bounds for arrays as does Fortran.
Third, C assumes a low bound of zero (0), while Fortran defaults to a
low bound of one (1) and can supports an arbitrary low bound.
Therefore, calculations must be done to determine what the C equivalent
of `A(5,10,20)' would be, and these calculations require knowing the
dimensions of `A'.
For `DIMENSION A(2:11,21,0:29)', the calculation of the offset of
`A(5,10,20)' would be:
(5-2)
+ (10-1)*(11-2+1)
+ (20-0)*(11-2+1)*(21-1+1)
= 4293
So the C equivalent in this case would be `a[4293]'.
When using a debugger directly on Fortran code, the C equivalent
might not work, because some debuggers cannot understand the notion of
low bounds other than zero. However, unlike `f2c', `g77' does inform
the GBE that a multi-dimensional array (like `A' in the above example)
is really multi-dimensional, rather than a single-dimensional array, so
at least the dimensionality of the array is preserved.
Debuggers that understand Fortran should have no trouble with
non-zero low bounds, but for non-Fortran debuggers, especially C
debuggers, the above example might have a C equivalent of `a[4305]'.
This calculation is arrived at by eliminating the subtraction of the
lower bound in the first parenthesized expression on each line--that
is, for `(5-2)' substitute `(5)', for `(10-1)' substitute `(10)', and
for `(20-0)' substitute `(20)'. Actually, the implication of this can
be that the expression `*(&a[2][1][0] + 4293)' works fine, but that
`a[20][10][5]' produces the equivalent of `*(&a[0][0][0] + 4305)'
because of the missing lower bounds.
Come to think of it, perhaps the behavior is due to the debugger
internally compensating for the lower bounds by offsetting the base
address of `a', leaving `&a' set lower, in this case, than
`&a[2][1][0]' (the address of its first element as identified by
subscripts equal to the corresponding lower bounds).
You know, maybe nobody really needs to use arrays.
File: ^.!gcc.docs.fortran.g77, Node: Procedures, Next: Adjustable Arrays, Prev: Arrays, Up: Debugging and Interfacing
Procedures (SUBROUTINE and FUNCTION)
====================================
Procedures that accept `CHARACTER' arguments are implemented by
`g77' so that each `CHARACTER' argument has two actual arguments.
The first argument occupies the expected position in the argument
list and has the user-specified name. This argument is a pointer to an
array of characters, passed by the caller.
The second argument is appended to the end of the user-specified
calling sequence and is named `__g77_length_X', where X is the
user-specified name. This argument is of the C type `ftnlen' (see
`gcc/f/runtime/f2c.h.in' for information on that type) and is the
number of characters the caller has allocated in the array pointed to
by the first argument.
A procedure will ignore the length argument if `X' is not declared
`CHARACTER*(*)', because for other declarations, it knows the length.
Not all callers necessarily "know" this, however, which is why they all
pass the extra argument.
The contents of the `CHARACTER' argument are specified by the
address passed in the first argument (named after it). The procedure
can read or write these contents as appropriate.
When more than one `CHARACTER' argument is present in the argument
list, the length arguments are appended in the order the orginal
arguments appear. So `CALL FOO('HI','THERE')' is implemented in C as
`foo("hi","there",2,5);', ignoring the fact that `g77' does not provide
the trailing null bytes on the constant strings (`f2c' does provide
them, but they are unnecessary in a Fortran environment, and you should
not expect them to be there).
Note that the above information applies to `CHARACTER' variables and
arrays *only*. It does *not* apply to external `CHARACTER' functions
or to intrinsic `CHARACTER' functions. That is, no second length
argument is passed to `FOO' in this case:
CHARACTER X
EXTERNAL X
CALL FOO(X)
Nor does `FOO' expect such an argument in this case:
SUBROUTINE FOO(X)
CHARACTER X
EXTERNAL X
Because of this implementation detail, if a program has a bug such
that there is disagreement as to whether an argument is a procedure,
and the type of the argument is `CHARACTER', subtle symptoms might
appear.
File: ^.!gcc.docs.fortran.g77, Node: Adjustable Arrays, Next: Alternate Returns, Prev: Procedures, Up: Debugging and Interfacing
Adjustable Arrays (DIMENSION)
=============================
Adjustable and automatic arrays in Fortran require the implementation
(in this case, the `g77' compiler) to "memorize" the expressions that
dimension the arrays each time the procedure is invoked. This is so
that subsequent changes to variables used in those expressions, made
during execution of the procedure, do not have any effect on the
dimensions of those arrays.
For example:
REAL ARRAY(5)
DATA ARRAY/5*2/
CALL X(ARRAY, 5)
END
SUBROUTINE X(A, N)
DIMENSION A(N)
N = 20
PRINT *, N, A
END
Here, the implementation should, when running the program, print
something like:
20 2. 2. 2. 2. 2.
Note that this shows that while the value of `N' was successfully
changed, the size of the `A' array remained at 5 elements.
To support this, `g77' generates code that executes before any user
code (and before the internally generated computed `GOTO' to handle
alternate entry points, as described below) that evaluates each
(nonconstant) expression in the list of subscripts for an array, and
saves the result of each such evaluation to be used when determining
the size of the array (instead of re-evaluating the expressions).
So, in the above example, when `X' is first invoked, code is
executed that copies the value of `N' to a temporary. And that same
temporary serves as the actual high bound for the single dimension of
the `A' array (the low bound being the constant 1). Since the user
program cannot (legitimately) change the value of the temporary during
execution of the procedure, the size of the array remains constant
during each invocation.
For alternate entry points, the code `g77' generates takes into
account the possibility that a dummy adjustable array is not actually
passed to the actual entry point being invoked at that time. In that
case, the public procedure implementing the entry point passes to the
master private procedure implementing all the code for the entry points
a `NULL' pointer where a pointer to that adjustable array would be
expected. The `g77'-generated code doesn't attempt to evaluate any of
the expressions in the subscripts for an array if the pointer to that
array is `NULL' at run time in such cases. (Don't depend on this
particular implementation by writing code that purposely passes `NULL'
pointers where the callee expects adjustable arrays, even if you know
the callee won't reference the arrays--nor should you pass `NULL'
pointers for any dummy arguments used in calculating the bounds of such
arrays or leave undefined any values used for that purpose in
COMMON--because the way `g77' implements these things might change in
the future!)
File: ^.!gcc.docs.fortran.g77, Node: Alternate Returns, Next: Functions, Prev: Adjustable Arrays, Up: Debugging and Interfacing
Alternate Returns (SUBROUTINE and RETURN)
=========================================
Subroutines with alternate returns (e.g. `SUBROUTINE X(*)' and `CALL
X(*50)') are implemented by `g77' as functions returning the C `int'
type. The actual alternate-return arguments are omitted from the
calling sequence. Instead, the caller uses the return value to do a
rough equivalent of the Fortran computed-`GOTO' statement, as in `GOTO
(50), X()' in the example above (where `X' is quietly declared as an
`INTEGER' function), and the callee just returns whatever integer is
specified in the `RETURN' statement for the subroutine For example,
`RETURN 1' is implemented as `X = 1' followed by `RETURN' in C, and
`RETURN' by itself is `X = 0' and `RETURN').
File: ^.!gcc.docs.fortran.g77, Node: Functions, Next: Common Blocks, Prev: Alternate Returns, Up: Debugging and Interfacing
Functions (FUNCTION and RETURN)
===============================
`g77' handles in a special way functions that return the following
types:
* `CHARACTER'
* `COMPLEX' (and `DOUBLE COMPLEX')
* `REAL'
For `CHARACTER', `g77' implements a subroutine (a C function
returning `void') with two arguments prepended: `__g77_result', which
the caller passes as a pointer to a `char' array expected to hold the
return value, and `__g77_length', which the caller passes as an
`ftnlen' value specifying the length of the return value as declared in
the calling program. For `CHARACTER'*(*), the called function uses
`__g77_length' to determine the size of the array that `__g77_result'
points to; otherwise, it ignores that argument.
For `COMPLEX' and `DOUBLE COMPLEX', when `-ff2c' is in force, `g77'
implements a subroutine with one argument prepended: `__g77_result',
which the caller passes as a pointer to a variable of the type of the
function. The called function writes the return value into this
variable instead of returning it as a function value. When `-fno-f2c'
is in force, `g77' implements a `COMPLEX' function as `gcc''s
`__complex__ float' function, returning the result of the function in
the same way as `gcc' would, and implements a `DOUBLE COMPLEX' function
similarly.
For `REAL', when `-ff2c' is in force, `g77' implements a function
that actually returns `DOUBLE PRECISION' (usually C's `double' type).
When `-fno-f2c' is in force, `REAL' functions return `float'.
File: ^.!gcc.docs.fortran.g77, Node: Common Blocks, Next: Local Equivalence Areas, Prev: Functions, Up: Debugging and Interfacing
Common Blocks (COMMON)
======================
`g77' names and lays out `COMMON' areas the same way f2c does, for
compatibility with f2c.
Currently, `g77' does not emit any debugging information for items
in a `COMMON' area, due to an apparent bug in the GBE.
Moreover, `g77' currently implements a `COMMON' area such that its
type is an array of the C `char' data type.
So, when debugging, you must know the offset into a `COMMON' area
for a particular item in that area, and you have to take into account
the appropriate multiplier for the respective sizes of the types (as
declared in your code) for the items preceding the item in question as
compared to the size of the `char' type.
For example, using default implicit typing, the statement
COMMON I(15), R(20), T
results in a public 144-byte `char' array named `_BLNK__' with `I'
placed at `_BLNK__[0]', `R' at `_BLNK__[60]', and `T' at `_BLNK__[140]'.
(This is assuming that the target machine for the compilation has
4-byte `INTEGER' and `REAL' types.)
File: ^.!gcc.docs.fortran.g77, Node: Local Equivalence Areas, Next: Alternate Entry Points, Prev: Common Blocks, Up: Debugging and Interfacing
Local Equivalence Areas (EQUIVALENCE)
=====================================
`g77' treats storage-associated areas involving a `COMMON' block as
explained in the section on common blocks.
A local `EQUIVALENCE' area is a collection of variables and arrays
connected to each other in any way via `EQUIVALENCE', none of which are
listed in a `COMMON' statement.
Currently, `g77' does not emit any debugging information for items
in a local `EQUIVALENCE' area, due to an apparent bug in the GBE.
Moreover, `g77' implements a local `EQUIVALENCE' area such that its
type is an array of the C `char' data type.
The name `g77' gives this array of `char' type is `__g77_equiv_X',
where X is the name of the first item listed in the `EQUIVALENCE'
statements for that area that is placed at the beginning (offset 0) of
this array.
When debugging, you must therefore access members of `EQUIVALENCE'
areas by specifying the appropriate `__g77_equiv_X' array section with
the appropriate offset. See the explanation of debugging `COMMON'
blocks for info applicable to debugging local `EQUIVALENCE' areas.
(Note: `g77' version 0.5.16 fixed a bug in how certain `EQUIVALENCE'
cases were handled. The bug caused the debugger to not know the size
of the array if any variable or array in the `EQUIVALENCE' was given an
initial value via `DATA' or similar.)
File: ^.!gcc.docs.fortran.g77, Node: Alternate Entry Points, Next: Assigned Statement Labels, Prev: Local Equivalence Areas, Up: Debugging and Interfacing
Alternate Entry Points (ENTRY)
==============================
The GBE does not understand the general concept of alternate entry
points as Fortran provides via the ENTRY statement. `g77' gets around
this by using an approach to compiling procedures having at least one
`ENTRY' statement that is almost identical to the approach used by
`f2c'. (An alternate approach could be used that would probably
generate faster, but larger, code that would also be a bit easier to
debug.)
Information on how `g77' implements `ENTRY' is provided for those
trying to debug such code. The choice of implementation seems unlikely
to affect code (compiled in other languages) that interfaces to such
code.
`g77' compiles exactly one public procedure for the primary entry
point of a procedure plus each `ENTRY' point it specifies, as usual.
That is, in terms of the public interface, there is no difference
between
SUBROUTINE X
END
SUBROUTINE Y
END
SUBROUTINE X
ENTRY Y
END
The difference between the above two cases lies in the code compiled
for the `X' and `Y' procedures themselves, plus the fact that, for the
second case, an extra internal procedure is compiled.
For every Fortran procedure with at least one `ENTRY' statement,
`g77' compiles an extra procedure named `__g77_masterfun_X', where X is
the name of the primary entry point (which, in the above case, using
the standard compiler options, would be `x_' in C).
This extra procedure is compiled as a private procedure--that is, a
procedure not accessible by name to separately compiled modules. It
contains all the code in the program unit, including the code for the
primary entry point plus for every entry point. (The code for each
public procedure is quite short, and explained later.)
The extra procedure has some other interesting characteristics.
The argument list for this procedure is invented by `g77'. It
contains a single integer argument named `__g77_which_entrypoint',
passed by value (as in Fortran's `%VAL()' intrinsic), specifying the
entry point index--0 for the primary entry point, 1 for the first entry
point (the first `ENTRY' statement encountered), 2 for the second entry
point, and so on.
It also contains, for functions returning `CHARACTER' and (when
`-ff2c' is in effect) `COMPLEX' functions, and for functions returning
different types among the `ENTRY' statements (e.g. `REAL FUNCTION R()'
containing `ENTRY I()'), an argument named `__g77_result' that is
expected at run time to contain a pointer to where to store the result
of the entry point. For `CHARACTER' functions, this storage area is an
array of the appropriate number of characters; for `COMPLEX' functions,
it is the appropriate area for the return type (currently either
`COMPLEX' or `DOUBLE COMPLEX'); for multiple- return-type functions, it
is a union of all the supported return types (which cannot include
`CHARACTER', since combining `CHARACTER' and non-`CHARACTER' return
types via `ENTRY' in a single function is not supported by `g77').
For `CHARACTER' functions, the `__g77_result' argument is followed
by yet another argument named `__g77_length' that, at run time,
specifies the caller's expected length of the returned value. Note
that only `CHARACTER*(*)' functions and entry points actually make use
of this argument, even though it is always passed by all callers of
public `CHARACTER' functions (since the caller does not generally know
whether such a function is `CHARACTER*(*)' or whether there are any
other callers that don't have that information).
The rest of the argument list is the union of all the arguments
specified for all the entry points (in their usual forms, e.g.
`CHARACTER' arguments have extra length arguments, all appended at the
end of this list). This is considered the "master list" of arguments.
The code for this procedure has, before the code for the first
executable statement, code much like that for the following Fortran
statement:
GOTO (100000,100001,100002), __g77_which_entrypoint
100000 ...code for primary entry point...
100001 ...code immediately following first ENTRY statement...
100002 ...code immediately following second ENTRY statement...
(Note that invalid Fortran statement labels and variable names are used
in the above example to highlight the fact that it represents code
generated by the `g77' internals, not code to be written by the user.)
It is this code that, when the procedure is called, picks which
entry point to start executing.
Getting back to the public procedures (`x' and `Y' in the original
example), those procedures are fairly simple. Their interfaces are
just like they would be if they were self-contained procedures (without
`ENTRY'), of course, since that is what the callers expect. Their code
consists of simply calling the private procedure, described above, with
the appropriate extra arguments (the entry point index, and perhaps a
pointer to a multiple-type- return variable, local to the public
procedure, that contains all the supported returnable non-character
types). For arguments that are not listed for a given entry point that
are listed for other entry points, and therefore that are in the
"master list" for the private procedure, null pointers (in C, the
`NULL' macro) are passed. Also, for entry points that are part of a
multiple-type- returning function, code is compiled after the call of
the private procedure to extract from the multi-type union the
appropriate result, depending on the type of the entry point in
question, returning that result to the original caller.
When debugging a procedure containing alternate entry points, you
can either set a break point on the public procedure itself (e.g. a
break point on `X' or `Y') or on the private procedure that contains
most of the pertinent code (e.g. `__g77_masterfun_X'). If you do the
former, you should use the debugger's command to "step into" the called
procedure to get to the actual code; with the latter approach, the
break point leaves you right at the actual code, skipping over the
public entry point and its call to the private procedure (unless you
have set a break point there as well, of course).
Further, the list of dummy arguments that is visible when the
private procedure is active is going to be the expanded version of the
list for whichever particular entry point is active, as explained
above, and the way in which return values are handled might well be
different from how they would be handled for an equivalent single-entry
function.
File: ^.!gcc.docs.fortran.g77, Node: Assigned Statement Labels, Prev: Alternate Entry Points, Up: Debugging and Interfacing
Assigned Statement Labels (ASSIGN and GOTO)
===========================================
For portability to machines where a pointer (such as to a label,
which is how `g77' implements `ASSIGN' and its cousin, the assigned
`GOTO') is wider (bitwise) than an `INTEGER', `g77' does not
necessarily use the same memory location to hold the `ASSIGN'ed value
of a variable as it does the numerical value in that variable, unless
the variable is wide enough (can hold enough bits).
In particular, while `g77' implements
I = 10
as, in C notation, `i = 10;', it might implement
ASSIGN 10 TO I
as, in GNU's extended C notation (for the label syntax),
`__g77_ASSIGN_I = &&L10;' (where `L10' is just a massaging of the
Fortran label `10' to make the syntax C-like; `g77' doesn't actually
generate the name `L10' or any other name like that, since debuggers
cannot access labels anyway).
While this currently means that an `ASSIGN' statement might not
overwrite the numeric contents of its target variable, *do not* write
any code depending on this feature. `g77' has already changed this
implementation across versions and might do so in the future. This
information is provided only to make debugging Fortran programs
compiled with the current version of `g77' somewhat easier. If there's
no debugger-visible variable named `__g77_ASSIGN_I' in a program unit
that does `ASSIGN 10 TO I', that probably means `g77' has decided it
can store the pointer to the label directly into `I' itself.
(Currently, `g77' always chooses to make the separate variable, to
improve the likelihood that `-O -Wuninitialized' will diagnose failures
to do things like `GOTO I' without `ASSIGN 10 TO I' despite doing
`I=5'.)
File: ^.!gcc.docs.fortran.g77, Node: Collected Fortran Wisdom, Next: Trouble, Prev: Debugging and Interfacing, Up: Top
Collected Fortran Wisdom
************************
Most users of `g77' can be divided into two camps:
* Those writing new Fortran code to be compiled by `g77'.
* Those using `g77' to compile existing, "legacy" code.
Users writing new code generally understand most of the necessary
aspects of Fortran to write "mainstream" code, but often need help
deciding how to handle problems, such as the construction of libraries
containing `BLOCK DATA'.
Users dealing with "legacy" code sometimes don't have much
experience with Fortran, but believe that the code they're compiling
already works when compiled by other compilers (and might not
understand why, as is sometimes the case, it doesn't work when compiled
by `g77').
The following information is designed to help users do a better job
coping with existing, "legacy" Fortran code, and with writing new code
as well.
* Menu:
* Overly Convenient Options:: Temptations to avoid, habits to not form.
* Block Data and Libraries:: How `g77' solves a common problem.
* Faster Programs:: Everybody wants these, but at what cost?
* Working Programs:: Getting programs to work should be done first.
* Loops:: Fortran `DO' loops surprise many people.
* Advantages Over f2c:: If `f2c' is so great, why `g77'?
File: ^.!gcc.docs.fortran.g77, Node: Overly Convenient Options, Next: Block Data and Libraries, Up: Collected Fortran Wisdom
Overly Convenient Command-line Options
======================================
These options should be used only as a quick-and-dirty way to
determine how well your program will run under different compilation
models without having to change the source. Some are more problematic
than others, depending on how portable and maintainable you want the
program to be (and, of course, whether you are allowed to change it at
all is crucial).
You should not continue to use these command-line options to compile
a given program, but rather should make changes to the source code:
`-finit-local-zero'
(This option specifies that any uninitialized local variables and
arrays have default initialization to binary zeros.)
Many other compilers do this automatically, which means lots of
Fortran code developed with those compilers depends on it.
It is safer (and probably would produce a faster program) to find
the variables and arrays that need such initialization and provide
it explicitly via `DATA', so that `-finit-local-zero' is not
needed.
Consider using `-Wuninitialized' (which requires `-O') to find
likely candidates, but do not specify `-finit-local-zero' or
`-fno-automatic', or this technique won't work.
`-fno-automatic'
(This option specifies that all local variables and arrays are to
be treated as if they were named in `SAVE' statements.)
Many other compilers do this automatically, which means lots of
Fortran code developed with those compilers depends on it.
The effect of this is that all variables and arrays are made
static, that is, not placed on the stack or in heap storage. This
might cause a buggy program to appear to work better. If so,
rather than relying on this command-line option (and hoping all
compilers provide the equivalent one), add `SAVE' statements to
some or all program unit sources, as appropriate. Consider using
`-Wuninitialized' (which requires `-O') to find likely candidates,
but do not specify `-finit-local-zero' or `-fno-automatic', or
this technique won't work.
The default is `-fautomatic', which tells `g77' to try and put
variables and arrays on the stack (or in fast registers) where
possible and reasonable. This tends to make programs faster.
`-fugly'
Fix the source code so that `-fno-ugly' will work. Note that, for
many programs, it is difficult to practically avoid using the
features enabled via `-fugly-init', and these features pose the
lowest risk of writing nonportable code, among the various "ugly"
features.
`-fGROUP-intrinsics-hide'
Change the source code to use `EXTERNAL' for any external procedure
that might be the name of an intrinsic. It is easy to find these
using `-fGROUP-intrinsics-disable'.
File: ^.!gcc.docs.fortran.g77, Node: Block Data and Libraries, Next: Faster Programs, Prev: Overly Convenient Options, Up: Collected Fortran Wisdom
Block Data and Libraries
========================
To ensure that block data program units are linked, especially a
concern when they are put into libraries, give each one a name (as in
`BLOCK DATA FOO') and make sure there is an `EXTERNAL FOO' statement in
every program unit that uses any common block initialized by the
corresponding `BLOCK DATA'. `g77' currently compiles a `BLOCK DATA' as
if it were a `SUBROUTINE', that is, it generates an actual procedure
having the appropriate name. The procedure does nothing but return
immediately if it happens to be called. For `EXTERNAL FOO', where
`FOO' is not otherwise referenced in the same program unit, `g77'
assumes there exists a `BLOCK DATA FOO' in the program and ensures that
by generating a reference to it so the linker will make sure it is
present. (Specifically, `g77' outputs in the data section a static
pointer to the external name `FOO'.)
The implementation `g77' currently uses to make this work is one of
the few things not compatible with `f2c' as currently shipped. `f2c'
currently does nothing with `EXTERNAL FOO' except issue a warning that
`FOO' is not otherwise referenced, and for `BLOCK DATA FOO', f2c
doesn't generate a dummy procedure with the name `FOO'. The upshot is
that you shouldn't mix `f2c' and `g77' in this particular case. If you
use f2c to compile `BLOCK DATA FOO', then any `g77'-compiled program
unit that says `EXTERNAL FOO' will result in an unresolved reference
when linked. If you do the opposite, then `FOO' might not be linked in
under various circumstances (such as when `FOO' is in a library, or
you're using a "clever" linker--so clever, it produces a broken program
with little or no warning by omitting initializations of global data
because they are contained in unreferenced procedures).
The changes you make to your code to make `g77' handle this
situation, however, appear to be a widely portable way to handle it.
That is, many systems permit it (as they should, since the FORTRAN 77
standard permits `EXTERNAL FOO' when `FOO' is a block data program
unit), and of the ones that might not link `BLOCK DATA FOO' under some
circumstances, most of them appear to do so once `EXTERNAL FOO' is
present in the appropriate program units.
File: ^.!gcc.docs.fortran.g77, Node: Faster Programs, Next: Working Programs, Prev: Block Data and Libraries, Up: Collected Fortran Wisdom
Faster Programs
===============
Aside from the usual `gcc' options, such as `-O', `-ffast-math', and
so on, consider trying:
`-fno-f2c'
Use this if you aren't linking with any code compiled using `f2c'.
(Note that `libf2c' is *not* an example of code that is compiled
using `f2c'--it is compiled by a C compiler, usually `gcc'.)
If you're using `-fno-automatic' already, you probably should change
your code to allow compilation with `-fautomatic' (the default), to
allow the program to run faster.
Similarly, you should be able to use `-fno-init-local-zero' (the
default) instead of `-finit-local-zero'. This is because it is rare
that every variable affected by these options in a given program
actually needs to be so affected.
For example, `-fno-automatic', which effectively `SAVE's every local
variable and array, affects even things like `DO' iteration variables,
which rarely need to be `SAVE'd, and this often reduces run-time
performances. Similarly, `-fno-init-local-zero' forces such variables
to be initialized to zero--when `SAVE'd (such as when
`-fno-automatic'), this by itself generally affects only startup time
for a program, but when not `SAVE'd, it can slow down the procedure
every time it is called.
*Note Overly Convenient Command-Line Options: Overly Convenient
Options, for information on the `-fno-automatic' and
`-finit-local-zero' options and how to convert their use into selective
changes in your own code.
File: ^.!gcc.docs.fortran.g77, Node: Working Programs, Next: Loops, Prev: Faster Programs, Up: Collected Fortran Wisdom
Working Programs
================
Getting Fortran programs to work in the first place can be quite a
challenge--even when the programs already work on other systems, or
when using other compilers.
`g77' offers some options that might be useful for tracking down
bugs in such programs. *Note Option Summary::, for a summary of these
and other options, and cross-references for each such option to the
pertinent material in this manual.
`-finit-local-zero'
A program that works better when compiled with this option is
depending on a particular system's, or compiler's, tendency to
initialize some variables to zero. It might be worthwhile finding
such cases and fixing them.
`-fno-automatic'
A program that works better when compiled with this option is
depending on not having to use the `SAVE' statement as required by
the Fortran standard. It might be worthwhile finding such cases
and fixing them.
`-Wimplicit'
This might catch failures to properly specify the types of
variables, arrays, and functions in the code. However, in code
that makes heavy use of Fortran's implicit-typing facility, this
option might produce so many warnings about cases that are
working, it would be hard to find the one or two that represent
bugs.
`-Wunused'
This can find bugs involving implicitly typing, sometimes more
easily than using -Wimplicit in code that makes heavy use of
implicit typing. An unused variable or array might indicate that
the spelling for its declaration is different from that of its
intended uses.
`-Wuninitialized'
This can find bugs involving uninitialized variables, which can in
turn result from misspellings in declaration statements.
`-Wsurprising'
This can find bugs involving expression evaluation or in the way
`DO' loops with non-integral iteration variables are handled.
Cases found by this option might indicate a difference of
interpretation between the author of the code involved, and a
standard-conforming compiler such as `g77'. Such a difference
might produce actual bugs.
In any case, changing the code to explicitly do what the
programmer might have expected it to do, so `g77' and other
compilers are more likely to follow the programmer's expectations,
might be worthwhile, especially if such changes make the program
work better.
It is possible that the "extra" warnings enabled by this option
could expose bugs in the code.
File: ^.!gcc.docs.fortran.g77, Node: Loops, Next: Advantages Over f2c, Prev: Working Programs, Up: Collected Fortran Wisdom
Loops
=====
The meaning of a `DO' loop in Fortran is precisely specified in the
Fortran standard...and is quite different from what many programmers
might expect.
In particular, Fortran `DO' loops are implemented as if the number
of trips through the loop is calculated *before* the loop is entered.
The number of trips for a loop is calculated from the START, END,
and INCREMENT values specified in a statement such as:
DO ITER = START, END, INCREMENT
The trip count is evaluated using a fairly simple formula based on
the three values following the `=' in the statement, and it is that
trip count that is effectively decremented during each iteration of the
loop. If, at the beginning of an iteration of the loop, the trip count
is zero or negative, the loop terminates. The per-loop-iteration
modifications to ITER are not related to determining whether to
terminate the loop.
There are two important things to remember about the trip count:
* It can be *negative*, in which case it is treated as if it was
zero--meaning the loop is not executed at all.
* The type used to *calculate* the trip count the same type as ITER,
but the final calculation, and thus the type of the trip count
itself, always is `INTEGER'.
These two items mean that there are loops that cannot be written in
straightforward fashion using the Fortran `DO'.
For example, on a system with the canonical 32-bit two's-complement
implementation of `INTEGER', the following loop will not work:
DO I = -2000000000, 2000000000
Although the START and END values are well within the range of
`INTEGER', the *trip count* is not. The expected trip count is
40000000001, which is outside the range of `INTEGER' on many systems.
Instead, the above loop should be constructed this way:
I = -2000000000
DO
IF (I .GT. 2000000000) EXIT
...
I = I + 1
END DO
The simple `DO' construct and the `EXIT' statement (used to leave the
innermost loop) are F90 features that `g77' supports.
Some Fortran compilers have buggy implementations of `DO', in that
they don't follow the standard. They implement `DO' as a
straightforward translation to what, in C, would be a `for' statement.
Instead of creating a temporary variable to hold the trip count as
calculated at run time, these compilers use the iteration variable ITER
to control whether the loop continues at each iteration.
The bug in such an implementation shows up when the trip count is
within the range of the type of ITER, but the magnitude of `ABS(END) +
ABS(INCR)' exceeds that range. For example:
DO I = 2147483600, 2147483647
A loop started by the above statement will work as implemented by
`g77', but the use, by some compilers, of a more C-like implementation
akin to
for (i = 2147483600; i <= 2147483647; ++i)
produces a loop that does not terminate, because `i' can never be
greater than 2147483647, since incrementing it beyond that value
overflows `i', setting it to -2147483648. This is a large, negative
number that still is less than 2147483647.
Another example of unexpected behavior of `DO' involves using a
nonintegral iteration variable ITER, such as a `REAL' or `DOUBLE
PRECISION' variable. Consider the following program:
DATA BEGIN, END, STEP /.1, .31, .007/
DO 10 R = BEGIN, END, STEP
IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
PRINT *,R
10 CONTINUE
PRINT *,'LAST = ',R
IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
END
A C-like view of `DO' would hold that the two "exclamatory" `PRINT' are
never executed. However, this is the output of running the above
program as compiled by `g77' on a Linux ix86 system:
.100000001
.107000001
.114
.120999999
...
.289000005
.296000004
.303000003
LAST = .310000002
.310000002 .LE. .310000002!!
Note that one of the two checks in the program turned up an apparent
violation of the programmer's expectation--yet, the loop is correctly
implemented by `g77', in that it has 30 iterations. This trip count of
30 is correct when evaluated using the floating-point representations
for the BEGIN, END, and INCR values (.1, .31, .007) on Linux ix86 are
used. On other systems, an apparently more accurate trip count of 31
might result, but, nevertheless, `g77' is faithfully following the
Fortran standard, and the result is not what the author of the sample
program above apparently expected. (Such other systems might, for
different values in the `DATA' statement, violate the other
programmer's expectation, for example.)
Due to this combination of imprecise representation of
floating-point values and the often-misunderstood interpretation of
`DO' by standard-conforming compilers such as `g77', use of `DO' loops
with `REAL' or `DOUBLE PRECISION' iteration variables is not
recommended. Such use can be caught by specifying `-Wsurprising'.
*Note Warning Options::, for more information on this option.
File: ^.!gcc.docs.fortran.g77, Node: Advantages Over f2c, Prev: Loops, Up: Collected Fortran Wisdom
Advantages Over f2c
===================
Without `f2c', `g77' would have taken much longer to do and probably
not been as good for quite a while. Sometimes people who notice how
much `g77' depends on, and documents encouragement to use, `f2c' ask
why `g77' was created if `f2c' already existed.
This section gives some basic answers to these questions, though it
is not intended to be comprehensive.
* Menu:
* Language Extensions:: Features used by Fortran code.
* Compiler Options:: Features helpful during development.
* Compiler Speed:: Speed of the compilation process.
* Program Speed:: Speed of the generated, optimized code.
* Ease of Debugging:: Debugging ease-of-use at the source level.
* Character and Hollerith Constants:: A byte saved is a byte earned.
File: ^.!gcc.docs.fortran.g77, Node: Language Extensions, Next: Compiler Options, Up: Advantages Over f2c
Language Extensions
-------------------
`g77' offers several extensions to the Fortran language that `f2c'
doesn't.
However, `f2c' offers a few that `g77' doesn't, like fairly complete
support for `INTEGER*2'. It is expected that `g77' will offer some or
all of these missing features at some time in the future. (Version
0.5.18 of `g77' offers some rudimentary support for some of these
features.)
File: ^.!gcc.docs.fortran.g77, Node: Compiler Options, Next: Compiler Speed, Prev: Language Extensions, Up: Advantages Over f2c
Compiler Options
----------------
`g77' offers a whole bunch of compiler options that `f2c' doesn't.
However, `f2c' offers a few that `g77' doesn't, like an option to
generate code to check array subscripts at run time. It is expected
that `g77' will offer some or all of these missing options at some time
in the future.
File: ^.!gcc.docs.fortran.g77, Node: Compiler Speed, Next: Program Speed, Prev: Compiler Options, Up: Advantages Over f2c
Compiler Speed
--------------
Saving the steps of writing and then rereading C code is a big reason
why `g77' should be able to compile code much faster than using `f2c'
in conjunction with the equivalent invocation of `gcc'.
However, due to `g77''s youth, lots of self-checking is still being
performed. As a result, this improvement is as yet unrealized (though
the potential seems to be there for quite a big speedup in the future).
It is possible that, as of version 0.5.18, `g77' is noticably faster
compiling many Fortran source files than using `f2c' in conjunction
with `gcc'.
File: ^.!gcc.docs.fortran.g77, Node: Program Speed, Next: Ease of Debugging, Prev: Compiler Speed, Up: Advantages Over f2c
Program Speed
-------------
`g77' has the potential to better optimize code than `f2c', even
when `gcc' is used to compile the output of `f2c', because `f2c' must
necessarily translate Fortran into a somewhat lower-level language (C)
that cannot preserve all the information that is potentially useful for
optimization, while `g77' can gather, preserve, and transmit that
information directly to the GBE.
For example, `g77' implements `ASSIGN' and assigned `GOTO' using
direct assignment of pointers to labels and direct jumps to labels,
whereas `f2c' maps the assigned labels to integer values and then uses
a C `switch' statement to encode the assigned `GOTO' statements.
However, as is typical, theory and reality don't quite match, at
least not in all cases, so it is still the case that `f2c' plus `gcc'
can generate code that is faster than `g77'.
It is hoped that version 0.5.18 of `g77' will offer default settings
and options that allow for better program speed, though it is not yet
known whether these same options, when applied to a `gcc' compilation
of `f2c' output, will improve the speed of programs compiled using that
method as well.
File: ^.!gcc.docs.fortran.g77, Node: Ease of Debugging, Next: Character and Hollerith Constants, Prev: Program Speed, Up: Advantages Over f2c
Ease of Debugging
-----------------
Because `g77' compiles directly to assembler code like `gcc',
instead of translating to an intermediate language (C) as does `f2c',
support for debugging can be better for `g77' than `f2c'.
However, although `g77' might be somewhat more "native" in terms of
debugging support than `f2c' plus `gcc', there still are a lot of
things "not quite right". Many of the important ones should be
resolved in the near future.
For example, `g77' doesn't have to worry about reserved names like
`f2c' does. Given `FOR = WHILE', `f2c' must necessarily translate this
to something *other* than `for = while;', because C reserves those
words.
However, `g77' does still uses things like an extra level of
indirection for `ENTRY'-laden procedures--in this case, because the
back end doesn't yet support multiple entry points.
Another example is that, given
COMMON A, B
EQUIVALENCE (B, C)
the `g77' user should be able to access the variables directly, by name,
without having to traverse C-like structures and unions, while `f2c' is
unlikely to ever offer this ability (due to limitations in the C
language).
However, due to apparent bugs in the back end, `g77' currently
doesn't take advantage of this facility at all--it doesn't emit any
debugging information for `COMMON' and `EQUIVALENCE' areas, other than
information on the array of `char' it creates (and, in the case of
local `EQUIVALENCE', names) for each such area.
Yet another example is arrays. `g77' represents them to the debugger
using the same "dimensionality" as in the source code, while `f2c' must
necessarily convert them all to one-dimensional arrays to fit into the
confines of the C language. However, the level of support offered by
debuggers for interactive Fortran-style access to arrays as compiled by
`g77' can vary widely. In some cases, it can actually be an advantage
that `f2c' converts everything to widely supported C semantics.
In fairness, `g77' could do many of the things `f2c' does to get
things working at least as well as `f2c'--for now, the maintainers have
tended to prefer making `g77' work the way they think it is supposed
to, and find help improving the other products (the GBE of `gcc';
`gdb'; and so on) to get things working properly.
File: ^.!gcc.docs.fortran.g77, Node: Character and Hollerith Constants, Prev: Ease of Debugging, Up: Advantages Over f2c
Character and Hollerith Constants
---------------------------------
To avoid the extensive hassle that would be needed to avoid this,
`f2c' uses C character constants to encode character and Hollerith
constants. That means a constant like `'HELLO'' is translated to
`"hello"' in C, which further means that an extra null byte is present
at the end of the constant. This null byte is superfluous.
`g77' does not generate such null bytes. This represents significant
savings of resources, such as on systems where `/dev/null' or
`/dev/zero' represent bottlenecks in the systems' performance, because
`g77' simply asks for fewer zeros from the operating system than `f2c'.
File: ^.!gcc.docs.fortran.g77, Node: Trouble, Next: Open Questions, Prev: Collected Fortran Wisdom, Up: Top
Known Causes of Trouble with GNU Fortran
****************************************
This section describes known problems that affect users of GNU
Fortran. Most of these are not GNU Fortran bugs per se--if they were,
we would fix them. But the result for a user may be like the result of
a bug.
Some of these problems are due to bugs in other software, some are
missing features that are too much work to add, and some are places
where people's opinions differ as to what is best.
Information on bugs that show up when configuring, porting, building,
or installing `g77' is not provided here. *Note Problems Installing::.
(Note that some of this portion of the manual is lifted directly
from the `gcc' manual, with minor modifications to tailor it to users
of `g77'. Anytime a bug seems to have more to do with the `gcc'
portion of `g77', *Note Known Causes of Trouble with GNU CC:
(gcc)Trouble.)
* Menu:
* But-bugs:: Bugs really in other programs.
* Actual Bugs:: Bugs and misfeatures we will fix later.
* Missing Features:: Features we already know we want to add later.
* Disappointments:: Regrettable things we can't change.
* Non-bugs:: Things we think are right, but some others disagree.
* Warnings and Errors:: Which problems in your code get warnings,
and which get errors.
File: ^.!gcc.docs.fortran.g77, Node: But-bugs, Next: Actual Bugs, Up: Trouble
Bugs Not In GNU Fortran
=======================
These are bugs to which the maintainers often have to reply, "but
that isn't a bug in `g77'...". Some of these already are fixed in new
versions of other software; some still need to be fixed; some are
problems with how `g77' is installed or is being used; some just cannot
be addressed at this time until more is known about the problem.
Please don't re-report these bugs to the `g77' maintainers--if you
must remind someone how important it is to you that the problem be
fixed, talk to the people responsible for the other products identified
below, but preferably only after you've tried the latest versions of
those products. The `g77' maintainers have their hands full working on
just fixing and improving `g77', without serving as a clearinghouse for
all bugs that happen to affect `g77' users.
*Note Collected Fortran Wisdom::, for information on behavior of
Fortran programs, and the programs that compile them, that might be
*thought* to indicate bugs.
* On some older Linux systems, programs with common blocks larger
than 16MB cannot be linked without some kind of error message
being produced.
This is a bug in older versions of `ld', fixed in more recent
versions of `binutils', such as version 2.6.
* There are some known problems when using `gdb' on code compiled by
`g77'. Inadequate investigation as of the release of 0.5.16
results in not knowing which products are the culprit, but
`gdb-4.14' definitely crashes when, for example, an attempt is
made to print the contents of a `COMPLEX*16' dummy array, on at
least some Linux machines, plus some others.
* On some systems, perhaps just those with out-of-date (shared?)
libraries, unresolved-reference errors happen when linking
`g77'-compiled programs (which should be done using `g77').
If this happens to you, try appending `-lc' to the command you use
to link the program, e.g. `g77 foo.f -lc'. `g77' already
specifies `-lf2c -lm' when it calls the linker, but it cannot also
specify `-lc' because not all systems have a file named `libc.a'.
It is unclear at this point whether there are legitimately
installed systems where `-lf2c -lm' is insufficient to resolve
code produced by `g77'.
* If your program doesn't link, due to unresolved references to names
like `_main', make sure you're using the `g77' command to do the
link, since this command ensures that the necessary libraries are
loaded by specifying `-lf2c -lm' when it invokes the `gcc' command
to do the actual link. (Use the `-v' option to discover more
about what actually happens when you use the `g77' and `gcc'
commands.)
Also, try specifying `-lc' as the last item on the `g77' command
line, because some systems need it and `g77' doesn't do it
automatically.
* Developers of Fortran code on NeXTStep (all architectures) have to
watch out for the following problem when writing programs with
large, statically allocated (i.e. non-stack based) data structures
(common blocks, saved arrays).
Due to the way the native loader (`/bin/ld') lays out data
structures in virtual memory, it is very easy to create an
executable wherein the `__DATA' segment overlaps (has addresses in
common) with the `UNIX STACK' segment.
This leads to all sorts of trouble, from the executable simply not
executing, to bus errors. The NeXTStep command line tool
`ebadexec' points to the problem as follows:
% `/bin/ebadexec a.out'
/bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
STACK segment (truncated address = 0x400000 rounded size =
0x3c00000) of executable file: a.out
(In the above case, it is the `__LINKEDIT' segment that overlaps
the stack segment.)
This can be cured by assigning the `__DATA' segment (virtual)
addresses beyond the stack segment. A conservative estimate for
this is from address 6000000 (hexadecimal) onwards--this has
always worked for me [Toon Moene]:
% `g77 -segaddr __DATA 6000000 test.f'
% `ebadexec a.out'
ebadexec: file: a.out appears to be executable
%
Browsing through `gcc/f/Makefile.in', you will find that the
`f771' program itself also has to be linked with these flags--it
has large statically allocated data structures. (Version 0.5.18
reduces this somewhat, but probably not enough.)
(The above item was contributed by Toon Moene
(`toon@moene.indiv.nluug.nl').)
* `g77' rejects some particularly nonportable, silent data-type
conversions such as `LOGICAL' to `REAL' (as in `A=.FALSE.', where
`A' is type `REAL'), that other compilers might quietly accept.
Some of these conversions are accepted by `g77' when the `-fugly'
option is specified.
File: ^.!gcc.docs.fortran.g77, Node: GPC Bugs
Known bugs and how to report bugs
*********************************
If you encounter a bug with GPC, please check whether it is one of
the known bugs. If not, report it to the GNU Pascal mailing list
`gpc@hut.fi'. (But always report it if you solve the problem! ;-)
Known bugs
==========
The GPC compiler does not yet implement the whole ISO 7185 Pascal
standard, so please take this into account when you consider using this
for any purpose.
See the file `version.c' to find out the version number of this GPC
(or run `gpc -v')
Problems in this GPC version:
* High optimization levels do not work properly on the Alpha. Some
conformance tests FAIL when compiled with -O6 flag, which means
that the compiler generates invalid code. Don't use this flag in
the alpha before the problem gets fixed. It might have something
to do with automatic inlining, but I have not yet looked at this.
-O flag should be ok. (Also take care when using explicit inline
functions)
* For some reason the pascal main program does not get lineno stabs
-> It is hard to debug it with gdb...
* The modules export everything, not just the stuff in the export
interfaces. However, the unexported variables and functions are
invisible to modules in other files.
* type checking is mostly what C does, not what Pascal requires, so
GPC does not yet implement a strongly typed language. Although
correct programs compile, incorrect ones compile also.
* run time errors are not checked.
* the inline set operations have some problems with operations on
two sets if the sets do not contain equally many segments.
* In addition, the set code generated in the alpha causes runtime
runtime errors in the generated code.
* Conformant arrays don't yet work (in general). Until they do,
this is a LEVEL-0 compiler.
Inconveniences
==============
* NEW & DISPOSE optional tag field arguments are ignored (warning
given, code works)
* GDB does not yet understand pascal sets, files or subranges. Now
GDB allows you to debug these things, even though it does not yet
understand some stabs.
* PACKED does not pack. (implementation dependent, warning given,
code works)
* Files of integer subranges that would fit in a byte do not;
instead they are handled as files of integer. This is especially
annoying with "file of 0..255".
Notes for debugging
===================
* Forward referencing pointers generate DBX style debugging symbols
by outputting the `.stabs' as an unknown pointer and later it just
outputs the same `.stabs' again, but this time it also tells what
type the pointer points to. This seems to work for gdb. As of
this writing I have not checked what happens with SDB type
debugging info. It might be that the pointer is left to be a
`(void *)' pointer, so you have to cast it in order to output the
object the pointer points to.
Also, I have not tried any other debugger than gdb. If you do,
please let me know what happens.
I think that GDB does not yet support the kind of `.stabs' that
should be used to do this correctly:
.stabs ":tANUMBER=BNUMBER", WHATEVER
where ANUMBER is the unknown pointer type referenced earlier, and
the BNUMBER is the type which ANUMBER actually is. This construct
is not required in C.
* When debugging, please note that the Initial Letter In Each
Identifier Is In Upper Case And The Rest Are In Lower Case. If
you wish to call C-routines declare them with the "C" directive,
as follows:
Procedure FooBAR(i:integer);c;
This makes the external name to be `_foobar' (replace `_' with you
machine prefix.)
Procedure FooBAR(i:Integer); External;
Uses external name `_Foobar'.
It is done like this to reduce name clashes with `libc.a' and
other possible libraries.
* All visible GPC runtime system library routines are named `_p_...'.
* However, the main program name is not capitalized. (this is a
kludge -> it may now clash with libc identifiers. We'll change
this somehow later)
File: ^.!gcc.docs.fortran.g77, Node: Missing Features, Next: Disappointments, Prev: Actual Bugs, Up: Trouble
Missing Features
================
This section lists features we know are missing from `g77', and
which we want to add someday. (There is no priority implied in the
ordering below.)
* `g77' does not support many of the features that distinguish
Fortran 90 (and, now, Fortran 95) from ANSI FORTRAN 77.
Some Fortran 90 features are listed here, because they make sense
to offer even to die-hard users of F77. For example, many of them
codify various ways F77 has been extended to meet users' needs
during its tenure, so `g77' might as well offer them as the primary
way to meet those same needs, even if it offers compatibility with
one or more of the ways those needs were met by other F77
compilers in the industry.
Still, many important F90 features are not listed here, because no
attempt has been made to research each and every feature and
assess its viability in `g77'. In the meantime, users who need
those features must use Fortran 90 compilers anyway, and the best
approach to adding some F90 features to GNU Fortran might well be
to fund a comprehensive project to create GNU Fortran 95.
* `g77' does not allow `REAL' and other non-integral types for
arguments to intrinsics like `AND', `OR', and `SHIFT'.
* `g77' doesn't support `INTEGER*2', `LOGICAL*1', and similar.
Version 0.6 will provide full support for this extremely important
set of features. In the meantime, version 0.5.18 provides
rudimentary support for them.
* `g77' rejects things other compilers accept, like `INTRINSIC
SIN,SIN'. As time permits in the future, some of these things
that are easy for humans to read and write and unlikely to be
intended to mean something else will be accepted by `g77' (though
`-fpedantic' should trigger warnings about such non-standard
constructs).
In the meantime, you might as well fix your code to be more
standard-conforming and portable.
The kind of case that is important to except from the
recommendation to change your code is one where following good
coding rules would force you to write non-standard code that
nevertheless has a clear meaning.
For example, when writing an `INCLUDE' file that defines a common
block, it might be appropriate to include a `SAVE' statement for
the common block (such as `SAVE /CBLOCK/'), so that variables
defined in the common block retain their values even when all
procedures declaring the common block become inactive (return to
their callers).
However, putting `SAVE' statements in an `INCLUDE' file would
prevent otherwise standard-conforming code from also specifying
the `SAVE' statement, by itself, to indicate that all local
variables and arrays are to have the `SAVE' attribute.
For this reason, `g77' already has been changed to allow this
combination, because although the general problem of gratuitously
rejecting unambiguous and "safe" constructs still exists in `g77',
this particular construct was deemed useful enough that it was
worth fixing `g77' for just this case.
So, while there is no need to change your code to avoid using this
particular construct, there might be other, equally appropriate
but non-standard constructs, that you shouldn't have to stop using
just because `g77' (or any other compiler) gratuitously rejects it.
Until the general problem is solved, if you have any such
construct you believe is worthwhile using (e.g. not just an
arbitrary, redundant specification of an attribute), please submit
a bug report with an explanation, so we can consider fixing `g77'
just for cases like yours.
* `g77' doesn't accept `PARAMETER I=1'. Supporting this obsolete
form of the `PARAMETER' statement would not be particularly hard,
as most of the parsing code is already in place and working.
Until time/money is spent implementing it, you might as well fix
your code to use the standard form, `PARAMETER (I=1)' (possibly
needing `INTEGER I' preceding the `PARAMETER' statement as well,
otherwise, in the obsolete form of `PARAMETER', the type of the
variable is set from the type of the constant being assigned to
it).
* `g77' doesn't support pointers or allocatable objects. This set
of features is probably considered just behind `INTEGER*2' and
intrinsics in `PARAMETER' statements on the list of large,
important things to add to `g77'.
* `g77' doesn't support the I/O statements `TYPE' and `ACCEPT'.
These are common extensions that should be easy to support, but
also are fairly easy to work around in user code.
* `g77' doesn't support `STRUCTURE', `UNION', `RECORD', `MAP'. This
set of extensions is quite a bit lower on the list of large,
important things to add to `g77', partly because it requires a
great deal of work either upgrading or replacing `libf2c'.
* There is no support for keywords such as `DISP='DELETE'' in the
`OPEN', `CLOSE', and `INQUIRE' statements. These extensions are
easy to add to `g77' itself, but require much more work on
`libf2c'.
* `g77' doesn't allow intrinsics in `PARAMETER' statements. This
feature is considered to be absolutely vital, even though it is
not standard-conforming, and is scheduled for version 0.6.
Related to this, `g77' doesn't allow non-integral exponentiation
in `PARAMETER' statements, such as `PARAMETER (R=2**.25)'. It is
unlikely `g77' will ever support this feature, as doing it
properly requires complete emulation of a target computer's
floating-point facilities when building `g77' as a cross-compiler.
But, if the `gcc' back end is enhanced to provide such a facility,
`g77' will likely use that facility in implementing this feature
soon afterwards.
* `g77' doesn't support `FORMAT(I<J>)' and the like. Supporting
this requires a significant redesign or replacement of `libf2c'.
* Need option to suppress information messages (notes). `-w' does
this but also suppresses warnings. The default should be to
suppress info messages.
* Provide some way, a la `gcc', for `g77' code to specify assembler
code.
* Support `INTEGER', `REAL', and `COMPLEX' equivalents for all
applicable back-end-supported types (`char', `short int', `int',
`long int', `long long int', and `long double'). This means
providing intrinsic support, and maybe constant support (using F90
syntax) as well, and, for most machines will result in automatic
support of `INTEGER*1', `INTEGER*2', `INTEGER*8', and so on. This
is scheduled for version 0.6.
* Provide as the default source-line model a "pure visual" mode,
where the interpretation of a source program in this mode can be
accurately determined by a user looking at a traditionally
displayed rendition of the program (assuming the user knows
whether the program is fixed or free form).
That is, assume the user cannot tell tabs from spaces and cannot
see trailing spaces on lines, but has canonical tab stops and, for
fixed-form source, has the ability to always know exactly where
column 72 is.
This would change the default treatment of fixed-form source to
not treat lines with tabs as if they were infinitely long--instead,
they would end at column 72 just as if the tabs were replaced by
spaces in the canonical way.
As part of this, provide common alternate models (Digital, `f2c',
and so on) via command-line options. This includes allowing
arbitrarily long lines for free-form source as well as fixed-form
source and providing various limits and diagnostics as appropriate.
* Support more general expressions to dimension arrays, such as
array element references, function references, etc.
* A `FLUSH' statement that does what many systems provide via `CALL
FLUSH', but that supports `*' as the unit designator (same unit as
for `PRINT').
* Finish support for old-style `PARAMETER' statement (like F77
`PARAMETER', but type of destination is set from type of source
expression).
* Character-type selector/cases for `SELECT CASE'.
* Option to initialize everything not explicitly initialized to
"weird" (machine-dependent) values, e.g. NANs, bad (non-`NULL')
pointers, and largest-magnitude integers.
* Add run-time bounds-checking of array/subscript references a la
`f2c'.
* Output labels for use by debuggers that know how to support them.
Same with weirder things like construct names. It is not yet
known if any debug formats or debuggers support these.
* Support the POSIX standard for Fortran.
* Support Digital-style lossage of virtual blanks at end of source
line if some command-line option specified.
This affects cases where a character constant is continued onto
the next line in a fixed-form source file, as in the following
example:
10 PRINT *,'HOW MANY
1 SPACES?'
`g77', and many other compilers, virtually extend the continued
line through column 72 with blanks that become part of the
character constant, but Digital Fortran normally didn't, leaving
only one space between `MANY' and `SPACES?' in the output of the
above statement.
Fairly recently, at least one version of Digital Fortran was
enhanced to provide the other behavior when a command-line option
is specified, apparently due to demand from readers of the USENET
group `comp.lang.fortran' to offer conformance to this widespread
practice in the industry. `g77' should return the favor by
offering conformance to Digital's approach to handling the above
example.
* Consider a preprocessor designed specifically for Fortran to
replace `cpp -traditional'. There are several out there worth
evaluating, at least.
* Have `-Wunused' warn about unused labels.
* Warn about assigned `GOTO'/`FORMAT' usage without any `ASSIGN' to
variable. (Actually, use of `-O -Wuninitialized' should take care
of most of these.)
* Add `-Wintrinsics' to warn about use of non-standard intrinsics
without explicit `INTRINSIC' statements for them (to help find
code that might fail silently when ported to another compiler).
* Support `-fpedantic' more thoroughly, and use it only to generate
warnings instead of rejecting constructs outright. Have it warn:
if a variable that dimensions an array is not a dummy or placed
explicitly in `COMMON' (F77 does not allow it to be placed in
`COMMON' via `EQUIVALENCE'); if specification statements follow
statement-function-definition statements; about all sorts of
syntactic extensions.
* Warn about modifying `DO' variables via `EQUIVALENCE'. (This test
might be useful in setting the internal "doiter" flag for a
variable or even array reference within a loop, since that might
produce faster code someday.)
* Add `-Wpromotions' to warn if source code appears to expect
automatic, silent, and somewhat dangerous compiler-assisted
conversion of `REAL' constants to `DOUBLE PRECISION' based on
context.
For example, warn about cases like this:
DOUBLE PRECISION FOO
PARAMETER (PI = 3.14159)
FOO = PI * 3D0
* Generally continue processing for warnings and recoverable (user)
errors whenever possible--don't gratuitously make bad code.
For example:
INTRINSIC ZABS
CALL FOO(ZABS)
END
When compiling the above with `-ff2c-intrinsics-disable', `g77'
should indeed complain about passing `ZABS', but it still should
compile, instead of rejecting the entire `CALL' statement. (Some
of this is related to improving the compiler internals to improve
how statements are analyzed.)
* If `-fno-ugly', reject badly designed trailing-radix quoted
(typeless) numbers, such as `'123'O'.
* Add `-Wugly*', `-Wautomatic', `-Wvxt-not-f90', `-Wf90', and so on.
These would warn about places in the user's source where
ambiguities are found.
One especially interesting case that `-Wf90' would catch is use of
`REAL(Z)', where `Z' is `DOUBLE COMPLEX'. Apparently, traditional
extended F77 compilers treat this as what all compilers should
agree is `REAL(REAL(Z))', while F90 compilers are required to
treat `REAL(Z)' as the same as `DBLE(Z)', returning a `DOUBLE
PRECISION' result rather than a `REAL' result.
* `-Wconversion' and related should flag places where non-standard
conversions are found. Perhaps much of this would be part of
`-Wugly*'.
* Complain when list of dummies containing an adjustable dummy array
does not also contain every variable listed in the dimension list
of the adjustable array.
Currently, `g77' does complain about a variable that dimensions an
array but doesn't appear in any dummy list or `COMMON' area, but
this needs to be extended to catch cases where it doesn't appear in
every dummy list that also lists any arrays it dimensions.
* Make sure things like `RETURN 2HAB' are invalid in both source
forms (must be `RETURN (2HAB)', which probably still makes no
sense but at least can be reliably parsed). Fixed form rejects
it, but not free form, except in a way that is a bit difficult to
understand.
* The sort of routines usually found in the BSD-ish `libU77' should
be provided in addition to the few utility routines in `libf2c'.
Much of this work has already been done, and is awaiting
integration into `g77'.
File: ^.!gcc.docs.fortran.g77, Node: Disappointments, Next: Non-bugs, Prev: Missing Features, Up: Trouble
Disappointments and Misunderstandings
=====================================
These problems are perhaps regrettable, but we don't know any
practical way around them for now.
* `g77' disallows `IMPLICIT CHARACTER*(*)'. This is not
standard-conforming, and there are some very good reasons for that.
When I next remember any, I'll try to write them down.
* `g77' doesn't allow a common block and an external procedure or
`BLOCK DATA' to have the same name. Some systems allow this, but
`g77' does not, to be compatible with `f2c'.
`g77' could special-case the way it handles `BLOCK DATA', since it
is not compatible with `f2c' in this particular area (necessarily,
since `g77' offers an important feature here), but it is likely
that such special-casing would be very annoying to people with
programs that use `EXTERNAL FOO', with no other mention of `FOO'
in the same program unit, to refer to external procedures, since
the result would be that `g77' would treat these references as
requests to force-load BLOCK DATA program units.
In that case, if `g77' modified names of `BLOCK DATA' so they
could have the same names as `COMMON', users would find that their
programs wouldn't link because the `FOO' procedure didn't have its
name translated the same way.
(Strictly speaking, `g77' could emit a
null-but-externally-satisfying definition of `FOO' with its name
transformed as if it had been a `BLOCK DATA', but that probably
invites more trouble than it's worth.)
* The current external-interface design, which includes naming of
external procedures, COMMON blocks, and the library interface, has
various usability problems, including things like adding
underscores where not really necessary (and preventing easier
inter-language operability) and yet not providing complete
namespace freedom for user C code linked with Fortran apps (due to
the naming of functions in the library, among other things).
Project GNU should at least get all this "right" for systems it
fully controls, such as the Hurd, and provide defaults and options
for compatibility with existing systems and interoperability with
popular existing compilers.
File: ^.!gcc.docs.fortran.g77, Node: Non-bugs, Next: Warnings and Errors, Prev: Disappointments, Up: Trouble
Certain Changes We Don't Want to Make
=====================================
This section lists changes that people frequently request, but which
we do not make because we think GNU Fortran is better without them.
* `-fno-backslash' should be the default, not `-fbackslash'.
First of all, you can always specify `-fno-backslash' to turn off
this processing.
Despite not being within the spirit (though apparently within the
letter) of the ANSI FORTRAN 77 standard, `g77' defaults to
`-fbackslash' because that is what most UNIX `f77' commands
default to, and apparently lots of code depends on this feature.
This is a particularly troubling issue. The use of a C construct
in the midst of Fortran code is bad enough, worse when it makes
existing Fortran programs stop working (as happens when programs
written for non-UNIX systems are ported to UNIX systems with
compilers that provide the `-fbackslash' feature as the
default--sometimes with no option to turn it off).
The author of GNU Fortran wished, for reasons of linguistic
purity, to make `-fno-backslash' the default for GNU Fortran and
thus require users of UNIX `f77' and `f2c' to specify
`-fbackslash' to get the UNIX behavior.
However, the realization that `g77' is intended as a replacement
for *UNIX* `f77', caused the author to choose to make `g77' as
compatible with `f77' as feasible, which meant making `-fbackslash'
the default.
The primary focus on compatibility is at the source-code level,
and the question became "What will users expect a replacement for
`f77' to do, by default?" Although at least one UNIX `f77' does
not provide `-fbackslash' as a default, it appears that, by far,
the majority of them do, which suggests that, by far, the majority
of code that is compiled by UNIX `f77' compilers expects
`-fbackslash' to be the default.
It is probably the case that more code exists that would *not*
work with `-fbackslash' in force than code that requires it be in
force.
However, most of *that* code is not being compiled with `f77', and
when it is, new build procedures (shell scripts, makefiles, and so
on) must be set up anyway so that they work under UNIX. That
makes a much more natural and safe opportunity for non-UNIX users
to adapt their build procedures for `g77''s default of
`-fbackslash' than would exist for the majority of UNIX `f77'
users who would have to modify existing, working build procedures
to explicitly specify `-fbackslash' if that was not the default.
One suggestion has been to configure the default for `-fbackslash'
(and perhaps other options as well) based on the configuration of
`g77'.
This is technically quite straightforward, but will be avoided
even in cases where not configuring defaults to be dependent on a
particular configuration greatly inconveniences some users of
legacy code.
Many users appreciate the GNU compilers because they provide an
environment that is uniform across machines. These users would be
inconvenienced if the compiler treated things like the format of
the source code differently on certain machines.
Occasionally users write programs intended only for a particular
machine type. On these occasions, the users would benefit if the
GNU Fortran compiler were to support by default the same dialect
as the other compilers on that machine. But such applications are
rare. And users writing a program to run on more than one type of
machine cannot possibly benefit from this kind of compatibility.
(This is consistent with the design goals for `gcc'. To change
them for `g77', you must first change them for `gcc'. Do not ask
the maintainers of `g77' to do this for you, or to disassociate
`g77' from the widely understood, if not widely agreed-upon, goals
for GNU compilers in general.)
This is why GNU Fortran does and will treat backslashes in the same
fashion on all types of machines (by default).
Of course, users strongly concerned about portability should
indicate explicitly in their build procedures which options are
expected by their source code, or write source code that has as
few such expectations as possible.
For example, avoid writing code that depends on backslash (`\')
being interpreted either way in particular, such as by starting a
program unit with:
CHARACTER BACKSL
PARAMETER (BACKSL = '\\')
Then, use concatenation of `BACKSL' anyplace a backslash is
desired. (However, this technique does not work for Hollerith
constants--which is good, since the only generally portable uses
for Hollerith constants are in places where character constants
can and should be used instead, for readability.)
In this way, users can write programs which have the same meaning
in many Fortran dialects.
* `g77' does not use context to determine the types of constants or
named constants (`PARAMETER').
For example, consider the following statement:
PRINT *, 3.1415926535 * 2D0
`g77' will interpret the (truncated) constant `3.1415926535' as a
`REAL', not `DOUBLE PRECISION', constant, because the suffix `D0'
is not specified.
As a result, the output of the above statement when compiled by
`g77' will appear to have "less precision" than when compiled by
other compilers.
In these and other cases, some compilers detect the fact that a
single-precision constant is used in a double-precision context
and therefore interpret the single-precision constant as if it was
*explicitly* specified as a double-precision constant. (This has
the effect of appending *decimal*, not *binary*, zeros to the
fractional part of the number--producing different computational
results.)
The reason this misfeature is dangerous is that a slight,
apparently innocuous change to the source code can change the
computational results. Consider:
REAL ALMOST, CLOSE
DOUBLE PRECISION FIVE
PARAMETER (ALMOST = 5.000000000001)
FIVE = 5
CLOSE = 5.000000000001
PRINT *, 5.000000000001 - FIVE
PRINT *, ALMOST - FIVE
PRINT *, CLOSE - FIVE
END
Running the above program should result in the same value being
printed three times. With `g77' as the compiler, it does.
However, compiled by many other compilers, running the above
program would print two or three distinct values, because in two
or three of the statements, the constant `5.000000000001', which
on most systems is exactly equal to `5.' when interpreted as a
single-precision constant, is instead interpreted as a
double-precision constant, preserving the represented precision.
However, this "clever" promotion of type does not extend to
variables or, in some compilers, to named constants.
Since programmers often are encouraged to replace manifest
constants or permanently-assigned variables with named constants
(`PARAMETER' in Fortran), and might need to replace some constants
with variables having the same values for pertinent portions of
code, it is important that compilers treat code so modified in the
same way so that the results of such programs are the same. `g77'
helps in this regard by treating constants just the same as
variables in terms of determining their types in a
context-independent way.
Still, there is a lot of existing Fortran code that has been
written to depend on the way other compilers freely interpret
constants' types based on context, so anything `g77' can do to
help flag cases of this in such code could be very helpful.
* `g77' treats procedure references to *possible* intrinsic names as
always enabling their intrinsic nature, regardless of whether the
*form* of the reference is valid for that intrinsic.
For example, `CALL IFIX' is interpreted by `g77' first as a
reference to the `IFIX' intrinsic, because the reference is a
procedure invocation (as compared to `J=IFIX'); only after
establishing that, in the program unit being compiled, `IFIX' is
in fact an intrinsic and not a local name that happens to have the
same name as an intrinsic, does `g77' recognize that the form of
the reference is invalid for that particular intrinsic. At that
point, `g77' issues a diagnostic.
Some users claim that it is "obvious" that `CALL IFIX' references
an external subroutine of their own, not an intrinsic function.
However, `g77' knows about intrinsic subroutines, not just
functions, and is able to support both having the same names, for
example.
As a result of this, `g77' rejects calls to intrinsics that are
not subroutines, and function invocations of intrinsics that are
not functions, just as it (and most compilers) rejects invocations
of intrinsics with the wrong number (or types) of arguments.
Use the `EXTERNAL IFIX' statement in a program unit that calls a
user-written subroutine named `IFIX'.
* Allow `DATA VAR/.../' to come before `COMMON /.../ ...,VAR,...'.
It is *possible* `g77' will someday allow this.
Then again, maybe it is better to have `g77' always require
placement of `DATA' so that it can possibly immediately write
constants to the output file, thus saving time and space.
That is, `DATA A/1000000*1/' should perhaps always be immediately
writable to canonical assembler, unless it's already known to be
in a `COMMON' area following as-yet-uninitialized stuff, and to do
this it cannot be followed by `COMMON A'.
* Making side effects happen in the same order as in some other
compiler.
It is never safe to depend on the order of evaluation of side
effects. For example, an expression like this may very well
behave differently from one compiler to another:
J = IFUNC() - IFUNC()
There is no guarantee that `IFUNC' will be evaluated in any
particular order. Either invocation might happen first. If
`IFUNC' returns 5 the first time it is invoked, and returns 12 the
second time, `J' might end up with the value `7', or it might end
up with `-7'.
Generally, in Fortran, procedures with side-effects intended to be
visible to the caller are best designed as *subroutines*, not
functions. Examples of such side-effects include:
* The generation of random numbers that are intended to
influence return values.
* Performing I/O (other than internal I/O to local variables).
* Updating information in common blocks.
An example of a side-effect that is not intended to be visible to
the caller is a function that maintains a cache of recently
calculated results, intended solely to speed repeated invocations
of the function with identical arguments. Such a function can be
safely used in expressions, because if the compiler optimizes away
one or more calls to the function, operation of the program is
unaffected (aside from being speeded up).
File: ^.!gcc.docs.fortran.g77, Node: Warnings and Errors, Prev: Non-bugs, Up: Trouble
Warning Messages and Error Messages
===================================
The GNU compiler can produce two kinds of diagnostics: errors and
warnings. Each kind has a different purpose:
*Errors* report problems that make it impossible to compile your
program. GNU Fortran reports errors with the source file name,
line number, and column within the line where the problem is
apparent.
*Warnings* report other unusual conditions in your code that
*might* indicate a problem, although compilation can (and does)
proceed. Warning messages also report the source file name, line
number, and column information, but include the text `warning:' to
distinguish them from error messages.
Warnings might indicate danger points where you should check to make
sure that your program really does what you intend; or the use of
obsolete features; or the use of nonstandard features of GNU Fortran.
Many warnings are issued only if you ask for them, with one of the `-W'
options (for instance, `-Wall' requests a variety of useful warnings).
*Note:* Currently, the text of the line and a pointer to the column
is printed in most `g77' diagnostics. Probably, as of version 0.6,
`g77' will no longer print the text of the source line, instead printing
the column number following the file name and line number in a form
that GNU Emacs recognizes. This change is expected to speed up and
reduce the memory usage of the `g77' compiler.
*Note Options to Request or Suppress Warnings: Warning Options, for
more detail on these and related command-line options.
File: ^.!gcc.docs.fortran.g77, Node: Open Questions, Next: Bugs, Prev: Trouble, Up: Top
Open Questions
**************
Please consider offering useful answers to these questions!
* `g77' treats constants like `Z'ABCD'' and `'ABCD'Z' as typeless.
It seems like maybe the prefix-letter form, `Z'ABCD'', should be
`INTEGER' instead.
You can test for yourself whether a particular compiler treats the
prefix form as `INTEGER' or typeless by running the following
program:
EQUIVALENCE (I, R)
R = Z'ABCD'
J = Z'ABCD'
IF (J .EQ. I) PRINT *, 'Prefix form is TYPELESS'
IF (J .NE. I) PRINT *, 'Prefix form is INTEGER'
END
If you wish to report the results of this test to the maintainers
of `g77', please include full information on the compiler, system,
and version information you're using. (We already know how `g77'
handles it, of course.)
Perhaps this will be changed in version 0.6.
* `LOC()' and other intrinsics are probably somewhat misclassified.
Is the a need for more precise classification of intrinsics, and
if so, what are the appropriate groupings? Is there a need to
individually enable/disable/delete/hide intrinsics from the
command line?
File: ^.!gcc.docs.fortran.g77, Node: Bugs, Next: Service, Prev: Open Questions, Up: Top
Reporting Bugs
**************
Your bug reports play an essential role in making GNU Fortran
reliable.
When you encounter a problem, the first thing to do is to see if it
is already known. *Note Trouble::. If it isn't known, then you should
report the problem.
Reporting a bug might help you by bringing a solution to your
problem, or it might not. (If it does not, look in the service
directory; see *Note Service::.) In any case, the principal function of
a bug report is to help the entire community by making the next version
of GNU Fortran work better. Bug reports are your contribution to the
maintenance of GNU Fortran.
Since the maintainers are very overloaded, we cannot respond to every
bug report. However, if the bug has not been fixed, we are likely to
send you a patch and ask you to tell us whether it works.
In order for a bug report to serve its purpose, you must include the
information that makes for fixing the bug.
* Menu:
* Criteria: Bug Criteria. Have you really found a bug?
* Where: Bug Lists. Where to send your bug report.
* Reporting: Bug Reporting. How to report a bug effectively.
* Patches: Sending Patches. How to send a patch for GNU Fortran.
* Known: Trouble. Known problems.
* Help: Service. Where to ask for help.
File: ^.!gcc.docs.fortran.g77, Node: Bug Criteria, Next: Bug Lists, Up: Bugs
Have You Found a Bug?
=====================
If you are not sure whether you have found a bug, here are some
guidelines:
* If the compiler gets a fatal signal, for any input whatever, that
is a compiler bug. Reliable compilers never crash--they just
remain obsolete.
* If the compiler produces invalid assembly code, for any input
whatever (except an `asm' statement), that is a compiler bug,
unless the compiler reports errors (not just warnings) which would
ordinarily prevent the assembler from being run.
* If the compiler produces valid assembly code that does not
correctly execute the input source code, that is a compiler bug.
However, you must double-check to make sure, because you might
have run into an incompatibility between GNU Fortran and
traditional Fortran. These incompatibilities might be considered
bugs, but they are inescapable consequences of valuable features.
Or you might have a program whose behavior is undefined, which
happened by chance to give the desired results with another
Fortran compiler. It is best to check the relevant Fortran
standard thoroughly if it is possible that the program indeed does
something undefined.
After you have localized the error to a single source line, it
should be easy to check for these things. If your program is
correct and well defined, you have found a compiler bug.
It might help if, in your submission, you identified the specific
language in the relevant Fortran standard that specifies the
desired behavior, if it isn't likely to be obvious and agreed-upon
by all Fortran users.
* If the compiler produces an error message for valid input, that is
a compiler bug.
* If the compiler does not produce an error message for invalid
input, that is a compiler bug. However, you should note that your
idea of "invalid input" might be someone else's idea of "an
extension" or "support for traditional practice".
* If you are an experienced user of Fortran compilers, your
suggestions for improvement of GNU Fortran are welcome in any case.
File: ^.!gcc.docs.fortran.g77, Node: Bug Lists, Next: Bug Reporting, Prev: Bug Criteria, Up: Bugs
Where to Report Bugs
====================
Send bug reports for GNU Fortran to `fortran@gnu.ai.mit.edu'.
Often people think of posting bug reports to a newsgroup instead of
mailing them. This sometimes appears to work, but it has one problem
which can be crucial: a newsgroup posting does not contain a mail path
back to the sender. Thus, if maintainers need more information, they
may be unable to reach you. For this reason, you should always send
bug reports by mail to the proper mailing list.
As a last resort, send bug reports on paper to:
GNU Compiler Bugs
Free Software Foundation
59 Temple Place - Suite 330
Boston, MA 02111-1307, USA
File: ^.!gcc.docs.fortran.g77, Node: Bug Reporting, Next: Sending Patches, Prev: Bug Lists, Up: Bugs
How to Report Bugs
==================
The fundamental principle of reporting bugs usefully is this:
*report all the facts*. If you are not sure whether to state a fact or
leave it out, state it!
Often people omit facts because they think they know what causes the
problem and they conclude that some details don't matter. Thus, you
might assume that the name of the variable you use in an example does
not matter. Well, probably it doesn't, but one cannot be sure.
Perhaps the bug is a stray memory reference which happens to fetch from
the location where that name is stored in memory; perhaps, if the name
were different, the contents of that location would fool the compiler
into doing the right thing despite the bug. Play it safe and give a
specific, complete example. That is the easiest thing for you to do,
and the most helpful.
Keep in mind that the purpose of a bug report is to enable someone to
fix the bug if it is not known. It isn't very important what happens if
the bug is already known. Therefore, always write your bug reports on
the assumption that the bug is not known.
Sometimes people give a few sketchy facts and ask, "Does this ring a
bell?" This cannot help us fix a bug, so it is rarely helpful. We
respond by asking for enough details to enable us to investigate. You
might as well expedite matters by sending them to begin with.
(Besides, there are enough bells ringing around here as it is.)
Try to make your bug report self-contained. If we have to ask you
for more information, it is best if you include all the previous
information in your response, as well as the information that was
missing.
Please report each bug in a separate message. This makes it easier
for us to track which bugs have been fixed and to forward your bugs
reports to the appropriate maintainer.
Do not compress and encode any part of your bug report using programs
such as `uuencode'. If you do so it will slow down the processing of
your bug. If you must submit multiple large files, use `shar', which
allows us to read your message without having to run any decompression
programs.
(As a special exception for GNU Fortran bug-reporting, at least for
now, if you are sending more than a few lines of code, if your
program's source file format contains "interesting" things like
trailing spaces or strange characters, or if you need to include binary
data files, it is acceptable to put all the files together in a `tar'
archive, and, whether you need to do that, it is acceptable to then
compress the single file (`tar' archive or source file) using `gzip'
and encode it via `uuencode'. Do not use any MIME stuff--the current
maintainer can't decode this. Using `compress' instead of `gzip' is
acceptable, assuming you have licensed the use of the patented
algorithm in `compress' from Unisys.)
To enable someone to investigate the bug, you should include all
these things:
* The version of GNU Fortran. You can get this by running `g77'
with the `-v' option. (Ignore any error messages that might be
displayed when the linker is run.)
Without this, we won't know whether there is any point in looking
for the bug in the current version of GNU Fortran.
* A complete input file that will reproduce the bug. If the bug is
in the compiler proper (`f771') and you are using the C
preprocessor, run your source file through the C preprocessor by
doing `g77 -E SOURCEFILE > OUTFILE', then include the contents of
OUTFILE in the bug report. (When you do this, use the same `-I',
`-D' or `-U' options that you used in actual compilation.)
A single statement is not enough of an example. In order to
compile it, it must be embedded in a complete file of compiler
input; and the bug might depend on the details of how this is done.
Without a real example one can compile, all anyone can do about
your bug report is wish you luck. It would be futile to try to
guess how to provoke the bug. For example, bugs in register
allocation and reloading frequently depend on every little detail
of the function they happen in.
* Note that you should include with your bug report any files
included by the source file (via the `INCLUDE' statement) that you
send, and any files they `INCLUDE', and so on.
It is not necessary to replace the `INCLUDE' statements with the
actual files in the version of the source file that you send, but
it might make submitting the bug report easier on the ends.
However, be sure to *reproduce* the bug using the *exact* version
of the source material you submit, to avoid wild-goose chases.
* The command arguments you gave GNU Fortran to compile that example
and observe the bug. For example, did you use `-O'? To guarantee
you won't omit something important, list all the options.
If we were to try to guess the arguments, we would probably guess
wrong and then we would not encounter the bug.
* The type of machine you are using, and the operating system name
and version number. (Much of this information is printed by `g77
-v'--if you include that, send along any additional info you have
that you don't see clearly represented in that output.)
* The operands you gave to the `configure' command when you installed
the compiler.
* A complete list of any modifications you have made to the compiler
source. (We don't promise to investigate the bug unless it
happens in an unmodified compiler. But if you've made
modifications and don't tell us, then you are sending us on a
wild-goose chase.)
Be precise about these changes. A description in English is not
enough--send a context diff for them.
Adding files of your own (such as a machine description for a
machine we don't support) is a modification of the compiler source.
* Details of any other deviations from the standard procedure for
installing GNU Fortran.
* A description of what behavior you observe that you believe is
incorrect. For example, "The compiler gets a fatal signal," or,
"The assembler instruction at line 208 in the output is incorrect."
Of course, if the bug is that the compiler gets a fatal signal,
then one can't miss it. But if the bug is incorrect output, the
maintainer might not notice unless it is glaringly wrong. None of
us has time to study all the assembler code from a 50-line Fortran
program just on the chance that one instruction might be wrong.
We need *you* to do this part!
Even if the problem you experience is a fatal signal, you should
still say so explicitly. Suppose something strange is going on,
such as, your copy of the compiler is out of synch, or you have
encountered a bug in the C library on your system. (This has
happened!) Your copy might crash and the copy here would not. If
you said to expect a crash, then when the compiler here fails to
crash, we would know that the bug was not happening. If you don't
say to expect a crash, then we would not know whether the bug was
happening. We would not be able to draw any conclusion from our
observations.
If the problem is a diagnostic when building GNU Fortran with some
other compiler, say whether it is a warning or an error.
Often the observed symptom is incorrect output when your program
is run. Sad to say, this is not enough information unless the
program is short and simple. None of us has time to study a large
program to figure out how it would work if compiled correctly,
much less which line of it was compiled wrong. So you will have
to do that. Tell us which source line it is, and what incorrect
result happens when that line is executed. A person who
understands the program can find this as easily as finding a bug
in the program itself.
* If you send examples of assembler code output from GNU Fortran,
please use `-g' when you make them. The debugging information
includes source line numbers which are essential for correlating
the output with the input.
* If you wish to mention something in the GNU Fortran source, refer
to it by context, not by line number.
The line numbers in the development sources don't match those in
your sources. Your line numbers would convey no convenient
information to the maintainers.
* Additional information from a debugger might enable someone to
find a problem on a machine which he does not have available.
However, you need to think when you collect this information if
you want it to have any chance of being useful.
For example, many people send just a backtrace, but that is never
useful by itself. A simple backtrace with arguments conveys little
about GNU Fortran because the compiler is largely data-driven; the
same functions are called over and over for different RTL insns,
doing different things depending on the details of the insn.
Most of the arguments listed in the backtrace are useless because
they are pointers to RTL list structure. The numeric values of the
pointers, which the debugger prints in the backtrace, have no
significance whatever; all that matters is the contents of the
objects they point to (and most of the contents are other such
pointers).
In addition, most compiler passes consist of one or more loops that
scan the RTL insn sequence. The most vital piece of information
about such a loop--which insn it has reached--is usually in a
local variable, not in an argument.
What you need to provide in addition to a backtrace are the values
of the local variables for several stack frames up. When a local
variable or an argument is an RTX, first print its value and then
use the GDB command `pr' to print the RTL expression that it points
to. (If GDB doesn't run on your machine, use your debugger to call
the function `debug_rtx' with the RTX as an argument.) In
general, whenever a variable is a pointer, its value is no use
without the data it points to.
Here are some things that are not necessary:
* A description of the envelope of the bug.
Often people who encounter a bug spend a lot of time investigating
which changes to the input file will make the bug go away and which
changes will not affect it.
This is often time consuming and not very useful, because the way
we will find the bug is by running a single example under the
debugger with breakpoints, not by pure deduction from a series of
examples. You might as well save your time for something else.
Of course, if you can find a simpler example to report *instead* of
the original one, that is a convenience. Errors in the output
will be easier to spot, running under the debugger will take less
time, etc. Most GNU Fortran bugs involve just one function, so
the most straightforward way to simplify an example is to delete
all the function definitions except the one where the bug occurs.
Those earlier in the file may be replaced by external declarations
if the crucial function depends on them. (Exception: inline
functions may affect compilation of functions defined later in the
file.)
However, simplification is not vital; if you don't want to do this,
report the bug anyway and send the entire test case you used.
* In particular, some people insert conditionals `#ifdef BUG' around
a statement which, if removed, makes the bug not happen. These
are just clutter; we won't pay any attention to them anyway.
Besides, you should send us preprocessor output, and that can't
have conditionals.
* A patch for the bug.
A patch for the bug is useful if it is a good one. But don't omit
the necessary information, such as the test case, on the
assumption that a patch is all we need. We might see problems
with your patch and decide to fix the problem another way, or we
might not understand it at all.
Sometimes with a program as complicated as GNU Fortran it is very
hard to construct an example that will make the program follow a
certain path through the code. If you don't send the example, we
won't be able to construct one, so we won't be able to verify that
the bug is fixed.
And if we can't understand what bug you are trying to fix, or why
your patch should be an improvement, we won't install it. A test
case will help us to understand.
*Note Sending Patches::, for guidelines on how to make it easy for
us to understand and install your patches.
* A guess about what the bug is or what it depends on.
Such guesses are usually wrong. Even the maintainer can't guess
right about such things without first using the debugger to find
the facts.
* A core dump file.
We have no way of examining a core dump for your type of machine
unless we have an identical system--and if we do have one, we
should be able to reproduce the crash ourselves.
File: ^.!gcc.docs.fortran.g77, Node: Sending Patches, Prev: Bug Reporting, Up: Bugs
Sending Patches for GNU Fortran
===============================
If you would like to write bug fixes or improvements for the GNU
Fortran compiler, that is very helpful. Send suggested fixes to the
bug report mailing list, `fortran@gnu.ai.mit.edu'.
Please follow these guidelines so we can study your patches
efficiently. If you don't follow these guidelines, your information
might still be useful, but using it will take extra work. Maintaining
GNU Fortran is a lot of work in the best of circumstances, and we can't
keep up unless you do your best to help.
* Send an explanation with your changes of what problem they fix or
what improvement they bring about. For a bug fix, just include a
copy of the bug report, and explain why the change fixes the bug.
(Referring to a bug report is not as good as including it, because
then we will have to look it up, and we have probably already
deleted it if we've already fixed the bug.)
* Always include a proper bug report for the problem you think you
have fixed. We need to convince ourselves that the change is
right before installing it. Even if it is right, we might have
trouble judging it if we don't have a way to reproduce the problem.
* Include all the comments that are appropriate to help people
reading the source in the future understand why this change was
needed.
* Don't mix together changes made for different reasons. Send them
*individually*.
If you make two changes for separate reasons, then we might not
want to install them both. We might want to install just one. If
you send them all jumbled together in a single set of diffs, we
have to do extra work to disentangle them--to figure out which
parts of the change serve which purpose. If we don't have time
for this, we might have to ignore your changes entirely.
If you send each change as soon as you have written it, with its
own explanation, then the two changes never get tangled up, and we
can consider each one properly without any extra work to
disentangle them.
Ideally, each change you send should be impossible to subdivide
into parts that we might want to consider separately, because each
of its parts gets its motivation from the other parts.
* Send each change as soon as that change is finished. Sometimes
people think they are helping us by accumulating many changes to
send them all together. As explained above, this is absolutely
the worst thing you could do.
Since you should send each change separately, you might as well
send it right away. That gives us the option of installing it
immediately if it is important.
* Use `diff -c' to make your diffs. Diffs without context are hard
for us to install reliably. More than that, they make it hard for
us to study the diffs to decide whether we want to install them.
Unidiff format is better than contextless diffs, but not as easy
to read as `-c' format.
If you have GNU diff, use `diff -cp', which shows the name of the
function that each change occurs in. (The maintainer of GNU
Fortran currently uses `diff -rcp2N'.)
* Write the change log entries for your changes. We get lots of
changes, and we don't have time to do all the change log writing
ourselves.
Read the `ChangeLog' file to see what sorts of information to put
in, and to learn the style that we use. The purpose of the change
log is to show people where to find what was changed. So you need
to be specific about what functions you changed; in large
functions, it's often helpful to indicate where within the
function the change was.
On the other hand, once you have shown people where to find the
change, you need not explain its purpose. Thus, if you add a new
function, all you need to say about it is that it is new. If you
feel that the purpose needs explaining, it probably does--but the
explanation will be much more useful if you put it in comments in
the code.
If you would like your name to appear in the header line for who
made the change, send us the header line.
* When you write the fix, keep in mind that we can't install a
change that would break other systems.
People often suggest fixing a problem by changing
machine-independent files such as `toplev.c' to do something
special that a particular system needs. Sometimes it is totally
obvious that such changes would break GNU Fortran for almost all
users. We can't possibly make a change like that. At best it
might tell us how to write another patch that would solve the
problem acceptably.
Sometimes people send fixes that *might* be an improvement in
general--but it is hard to be sure of this. It's hard to install
such changes because we have to study them very carefully. Of
course, a good explanation of the reasoning by which you concluded
the change was correct can help convince us.
The safest changes are changes to the configuration files for a
particular machine. These are safe because they can't create new
bugs on other machines.
Please help us keep up with the workload by designing the patch in
a form that is good to install.
File: ^.!gcc.docs.fortran.g77, Node: Service, Next: Index, Prev: Bugs, Up: Top
How To Get Help with GNU Fortran
********************************
If you need help installing, using or changing GNU Fortran, there
are two ways to find it:
* Look in the service directory for someone who might help you for a
fee. The service directory is found in the file named `SERVICE'
in the GNU CC distribution.
* Send a message to `fortran@gnu.ai.mit.edu'.
File: ^.!gcc.docs.fortran.g77, Node: Index, Prev: Service, Up: Top
Index
*****
* Menu:
* #define: Overall Options.
* #if: Overall Options.
* #include: Overall Options.
* %DESCR() intrinsic <1>: Changes.
* %DESCR() intrinsic: Extensions.
* %LOC() intrinsic: Extensions.
* %REF() intrinsic: Extensions.
* %VAL() intrinsic: Extensions.
* *N notation: Types.
* --driver option <1>: G77 and GCC.
* --driver option: Invoking G77.
* -fGROUP-intrinsics-hide option: Overly Convenient Options.
* -fcaller-saves option: Optimize Options.
* -fcase-initcap option: Fortran Dialect Options.
* -fcase-lower option: Fortran Dialect Options.
* -fcase-preserve option: Fortran Dialect Options.
* -fcase-strict-lower option: Fortran Dialect Options.
* -fcase-strict-upper option: Fortran Dialect Options.
* -fcase-upper option: Fortran Dialect Options.
* -fdcp-intrinsics-delete option: Fortran Dialect Options.
* -fdcp-intrinsics-disable option: Fortran Dialect Options.
* -fdcp-intrinsics-enable option: Fortran Dialect Options.
* -fdcp-intrinsics-hide option: Fortran Dialect Options.
* -fdelayed-branch option: Optimize Options.
* -fdollar-ok option: Fortran Dialect Options.
* -fexpensive-optimizations option: Optimize Options.
* -ff2c-intrinsics-delete option: Fortran Dialect Options.
* -ff2c-intrinsics-disable option: Fortran Dialect Options.
* -ff2c-intrinsics-enable option: Fortran Dialect Options.
* -ff2c-intrinsics-hide option: Fortran Dialect Options.
* -ff2c-library option: Code Gen Options.
* -ff90 option: Fortran Dialect Options.
* -ff90-intrinsics-delete option: Fortran Dialect Options.
* -ff90-intrinsics-disable option: Fortran Dialect Options.
* -ff90-intrinsics-enable option: Fortran Dialect Options.
* -ff90-intrinsics-hide option: Fortran Dialect Options.
* -ff90-not-vxt option: Fortran Dialect Options.
* -ffast-math option: Optimize Options.
* -ffixed-line-length-N option: Fortran Dialect Options.
* -ffloat-store option: Optimize Options.
* -fforce-addr option: Optimize Options.
* -fforce-mem option: Optimize Options.
* -ffree-form option: Fortran Dialect Options.
* -finit-local-zero option <1>: Overly Convenient Options.
* -finit-local-zero option: Code Gen Options.
* -fintrin-case-any option: Fortran Dialect Options.
* -fintrin-case-initcap option: Fortran Dialect Options.
* -fintrin-case-lower option: Fortran Dialect Options.
* -fintrin-case-upper option: Fortran Dialect Options.
* -fmatch-case-any option: Fortran Dialect Options.
* -fmatch-case-initcap option: Fortran Dialect Options.
* -fmatch-case-lower option: Fortran Dialect Options.
* -fmatch-case-upper option: Fortran Dialect Options.
* -fmil-intrinsics-delete option: Fortran Dialect Options.
* -fmil-intrinsics-disable option: Fortran Dialect Options.
* -fmil-intrinsics-enable option: Fortran Dialect Options.
* -fmil-intrinsics-hide option: Fortran Dialect Options.
* -fno-automatic option <1>: Overly Convenient Options.
* -fno-automatic option: Code Gen Options.
* -fno-backslash option: Fortran Dialect Options.
* -fno-common option: Code Gen Options.
* -fno-f2c option <1>: Faster Programs.
* -fno-f2c option: Code Gen Options.
* -fno-fixed-form option: Fortran Dialect Options.
* -fno-ident option: Code Gen Options.
* -fno-inline option: Optimize Options.
* -fno-second-underscore option: Code Gen Options.
* -fno-ugly-args option: Warning Options.
* -fno-ugly-init option: Warning Options.
* -fno-underscoring option: Code Gen Options.
* -fpack-struct option: Code Gen Options.
* -fpcc-struct-return option: Code Gen Options.
* -fpedantic option: Warning Options.
* -freg-struct-return option: Code Gen Options.
* -frerun-cse-after-loop option: Optimize Options.
* -fschedule-insns option: Optimize Options.
* -fschedule-insns2 option: Optimize Options.
* -fset-g77-defaults option: Overall Options.
* -fshort-double option: Code Gen Options.
* -fsource-case-lower option: Fortran Dialect Options.
* -fsource-case-preserve option: Fortran Dialect Options.
* -fsource-case-upper option: Fortran Dialect Options.
* -fstrength-reduce option: Optimize Options.
* -fsymbol-case-any option: Fortran Dialect Options.
* -fsymbol-case-initcap option: Fortran Dialect Options.
* -fsymbol-case-lower option: Fortran Dialect Options.
* -fsymbol-case-upper option: Fortran Dialect Options.
* -fsyntax-only option: Warning Options.
* -fugly option <1>: Overly Convenient Options.
* -fugly option: Warning Options.
* -funix-intrinsics-delete option: Fortran Dialect Options.
* -funix-intrinsics-disable option: Fortran Dialect Options.
* -funix-intrinsics-enable option: Fortran Dialect Options.
* -funix-intrinsics-hide option: Fortran Dialect Options.
* -funroll-all-loops option: Optimize Options.
* -funroll-loops option: Optimize Options.
* -fversion option: Overall Options.
* -fvxt-intrinsics-delete option: Fortran Dialect Options.
* -fvxt-intrinsics-disable option: Fortran Dialect Options.
* -fvxt-intrinsics-enable option: Fortran Dialect Options.
* -fvxt-intrinsics-hide option: Fortran Dialect Options.
* -fvxt-not-f90 option: Fortran Dialect Options.
* -fzeros option: Code Gen Options.
* -g option: Debugging Options.
* -I- option: Directory Options.
* -Idir option: Directory Options.
* -pedantic option: Warning Options.
* -pedantic-errors option: Warning Options.
* -u option: Warning Options.
* -v option: G77 and GCC.
* -w option: Warning Options.
* -Waggregate-return option: Warning Options.
* -Wall option: Warning Options.
* -Wcomment option: Warning Options.
* -Wconversion option: Warning Options.
* -Werror option: Warning Options.
* -Wformat option: Warning Options.
* -Wid-clash-LEN option: Warning Options.
* -Wimplicit option: Warning Options.
* -Wlarger-than-LEN option: Warning Options.
* -Wparentheses option: Warning Options.
* -Wredundant-decls option: Warning Options.
* -Wshadow option: Warning Options.
* -Wsurprising option: Warning Options.
* -Wswitch option: Warning Options.
* -Wtraditional option: Warning Options.
* -Wuninitialized option: Warning Options.
* -Wunused option: Warning Options.
* .F: Overall Options.
* .fpp: Overall Options.
* /WARNINGS=DECLARATIONS switch: Warning Options.
* 64-bit systems: Alpha Problems.
* bison: Missing bison?.
* g77, installation of: Installation of Binaries.
* gcc versions supported by g77: Merging Distributions.
* gcc, installation of: Installation of Binaries.
* gdb support: But-bugs.
* makeinfo: Missing makeinfo?.
* ABORT() intrinsic: Fortran Dialect Options.
* ACCEPT statement: Missing Features.
* adjustable arrays: Adjustable Arrays.
* aggregate initialization: Large Initialization.
* all warnings: Warning Options.
* Alpha, bugs: Alpha Problems.
* alternate entry points: Alternate Entry Points.
* alternate returns: Alternate Returns.
* AND intrinsic: Missing Features.
* ANSI FORTRAN 77 support: Standard Support.
* arguments, unused: Warning Options.
* array ordering: Arrays.
* arrays: Arrays.
* arrays, adjustable: Adjustable Arrays.
* arrays, automatic: Adjustable Arrays.
* arrays, dimensioning: Adjustable Arrays.
* as command: What is GNU Fortran?.
* assembler: What is GNU Fortran?.
* assembly code: What is GNU Fortran?.
* assembly code, invalid: Bug Criteria.
* ASSIGN statement: Assigned Statement Labels.
* assigned statement labels: Assigned Statement Labels.
* automatic arrays: Adjustable Arrays.
* back end, gcc: What is GNU Fortran?.
* backslash <1>: Fortran Dialect Options.
* backslash: Non-bugs.
* backtrace for bug reports: Bug Reporting.
* basic concepts: What is GNU Fortran?.
* beginners: Getting Started.
* binaries, distributing: Distributing Binaries.
* bit patterns: Floating-point Bit Patterns.
* block data: Disappointments.
* block data and libraries: Block Data and Libraries.
* BLOCK DATA statement <1>: Block Data and Libraries.
* BLOCK DATA statement: Disappointments.
* bootstrap build: Bootstrap Build.
* bug criteria: Bug Criteria.
* bug report mailing lists: Bug Lists.
* bugs <1>: What is GNU Fortran?.
* bugs: Bugs.
* bugs, known: Trouble.
* build, bootstrap: Bootstrap Build.
* build, straight: Straight Build.
* building g77: Building gcc.
* building gcc: Building gcc.
* but-bugs: But-bugs.
* C preprocessor: Overall Options.
* C routines calling Fortran: Debugging and Interfacing.
* calling C routines: Debugging and Interfacing.
* card image: Fortran Dialect Options.
* carriage returns: Source Form.
* case sensitivity: Case Sensitivity.
* cc1 program: What is GNU Fortran?.
* cc1plus program: What is GNU Fortran?.
* changes, user-visible: Changes.
* character constants <1>: Fortran Dialect Options.
* character constants <1>: Distensions.
* character constants <1>: Dialects.
* character constants: Character and Hollerith Constants.
* character set: Fortran Dialect Options.
* characters, comment: Dialects.
* characters, continuation: Dialects.
* CLOSE statement: Missing Features.
* code generation conventions: Code Gen Options.
* code generator: What is GNU Fortran?.
* code, assembly: What is GNU Fortran?.
* code, distributing: Distributing Binaries.
* code, in-line: What is GNU Fortran?.
* code, legacy: Collected Fortran Wisdom.
* code, machine: What is GNU Fortran?.
* code, modifying: Unpacking.
* code, object: Object Compatibility.
* code, source <1>: What is GNU Fortran?.
* code, source <1>: Case Sensitivity.
* code, source <1>: Unpacking.
* code, source: Source Form.
* code, stack variables: Maximum Stackable Size.
* code, user: But-bugs.
* code, writing: Collected Fortran Wisdom.
* column-major ordering: Arrays.
* command options: Invoking G77.
* commands, as: What is GNU Fortran?.
* commands, f77: Installing f77.
* commands, g77 <1>: G77 and GCC.
* commands, g77: What is GNU Fortran?.
* commands, gcc <1>: G77 and GCC.
* commands, gcc: What is GNU Fortran?.
* commands, gdb: What is GNU Fortran?.
* commands, ld: What is GNU Fortran?.
* comment character: Dialects.
* COMMON blocks: Debugging Options.
* common blocks: Common Blocks.
* common blocks, large: But-bugs.
* COMMON statement <1>: Common Blocks.
* COMMON statement: Disappointments.
* compatibility <1>: Object Compatibility.
* compatibility <1>: Block Data and Libraries.
* compatibility: Faster Programs.
* compatibility, f2c: Code Gen Options.
* compilation, in-line: Optimize Options.
* compilation, pedantic: Pedantic Compilation.
* compiler bugs, reporting: Bug Reporting.
* compilers: What is GNU Fortran?.
* compilers, compatibility: Object Compatibility.
* compiling programs: G77 and GCC.
* COMPLEX intrinsics: Fortran Dialect Options.
* COMPLEX type: Types.
* components of g77: What is GNU Fortran?.
* concepts, basic: What is GNU Fortran?.
* conformance, IEEE: Optimize Options.
* constants: Constants.
* constants, character <1>: Dialects.
* constants, character <1>: Distensions.
* constants, character: Character and Hollerith Constants.
* constants, Hollerith <1>: Distensions.
* constants, Hollerith <1>: Character and Hollerith Constants.
* constants, Hollerith: Changes.
* constants, octal: Dialects.
* constants, typeless: Changes.
* continuation character: Dialects.
* contributors: Contributors.
* core dump: Bug Criteria.
* cpp preprocessor: Overall Options.
* cpp program <1>: Bug Reporting.
* cpp program <1>: Preprocessor Options.
* cpp program <1>: What is GNU Fortran?.
* cpp program: Overall Options.
* Cray pointers: Missing Features.
* creating patch files: Merging Distributions.
* credits: Contributors.
* cross-compilation: Cross-compiler Problems.
* cross-compiler, building: Floating-point Bit Patterns.
* DATA statement: Code Gen Options.
* data types: Types.
* debugger: What is GNU Fortran?.
* debugging <1>: Main Program Unit.
* debugging: Debugging and Interfacing.
* debugging information options: Debugging Options.
* debug_rtx: Bug Reporting.
* deleted intrinsics: Intrinsics.
* diagnostics, incorrect: What is GNU Fortran?.
* dialect options: Fortran Dialect Options.
* dialects of language: Dialects.
* Digital Fortran features: Fortran Dialect Options.
* DIMENSION statement <1>: Adjustable Arrays.
* DIMENSION statement: Arrays.
* dimensioning arrays: Adjustable Arrays.
* directory options: Directory Options.
* directory search paths for inclusion: Directory Options.
* directory, updating info: Updating Documentation.
* disabled intrinsics: Intrinsics.
* disposition of files: Missing Features.
* distensions: Distensions.
* distributions, unpacking: Unpacking.
* distributions, why separate: Merging Distributions.
* DO statement <1>: Loops.
* DO statement: Warning Options.
* documentation: Updating Documentation.
* dollar sign: Fortran Dialect Options.
* DOUBLE COMPLEX type: Types.
* DOUBLE PRECISION type: Types.
* double quotes: Dialects.
* driver, gcc command as: What is GNU Fortran?.
* dummies, unused: Warning Options.
* effecting IMPLICIT NONE: Warning Options.
* enabled intrinsics: Intrinsics.
* entry points: Alternate Entry Points.
* ENTRY statement: Alternate Entry Points.
* environment variables: Environment Variables.
* EQUIVALENCE areas: Debugging Options.
* equivalence areas: Local Equivalence Areas.
* EQUIVALENCE statement: Local Equivalence Areas.
* error messages: Warnings and Errors.
* error messages, incorrect: What is GNU Fortran?.
* errors, linker: But-bugs.
* exclamation points: Dialects.
* executable file: What is GNU Fortran?.
* EXIT() intrinsic: Fortran Dialect Options.
* extended-source option: Fortran Dialect Options.
* extensions: Extensions.
* extensions, file name: Overall Options.
* extensions, VXT: Dialects.
* extra warnings: Warning Options.
* f2c compatibility <1>: Debugging and Interfacing.
* f2c compatibility <1>: Code Gen Options.
* f2c compatibility <1>: Block Data and Libraries.
* f2c compatibility <1>: Faster Programs.
* f2c compatibility: Object Compatibility.
* f2c intrinsics: Fortran Dialect Options.
* F2CLIBOK: Installing f2c.
* F2C_INSTALL_FLAG: Installing f2c.
* f77 command: Installing f77.
* f77 support: Non-bugs.
* f771 program: What is GNU Fortran?.
* f771, linking error for: General Problems.
* F77_INSTALL_FLAG: Installing f77.
* fatal signal: Bug Criteria.
* features, ugly <1>: Distensions.
* features, ugly: Warning Options.
* FFE: What is GNU Fortran?.
* FFECOM_sizeMAXSTACKITEM: Maximum Stackable Size.
* file format not recognized: What is GNU Fortran?.
* file name extension: Overall Options.
* file name suffix: Overall Options.
* file type: Overall Options.
* file, source: What is GNU Fortran?.
* files, executable: What is GNU Fortran?.
* files, source: Source Form.
* fixed form <1>: Source Form.
* fixed form: Fortran Dialect Options.
* fixed-form line length: Fortran Dialect Options.
* floating-point bit patterns: Floating-point Bit Patterns.
* FLUSH() intrinsic: Fortran Dialect Options.
* FORMAT statement: Missing Features.
* Fortran 90 features <1>: Fortran Dialect Options.
* Fortran 90 features <1>: Dialects.
* Fortran 90 features: Fortran Dialect Options.
* Fortran 90 intrinsics: Fortran Dialect Options.
* Fortran 90 support: Missing Features.
* Fortran preprocessor: Overall Options.
* free form <1>: Fortran Dialect Options.
* free form: Source Form.
* front end, g77: What is GNU Fortran?.
* FSF, funding the: Funding GNU Fortran.
* FUNCTION statement <1>: Functions.
* FUNCTION statement: Procedures.
* functions: Functions.
* functions, intrinsic: Fortran Dialect Options.
* funding improvements: Funding GNU Fortran.
* funding the FSF: Funding GNU Fortran.
* g77 command <1>: What is GNU Fortran?.
* g77 command: G77 and GCC.
* g77 front end: What is GNU Fortran?.
* g77 options, -driver: G77 and GCC.
* g77 options, -v: G77 and GCC.
* g77 options, driver: Invoking G77.
* g77, components of: What is GNU Fortran?.
* GBE <1>: What is GNU Fortran?.
* GBE: General Problems.
* gcc back end: What is GNU Fortran?.
* gcc command <1>: G77 and GCC.
* gcc command: What is GNU Fortran?.
* gcc command as driver: What is GNU Fortran?.
* gcc not recognizing Fortran source: What is GNU Fortran?.
* gdb command: What is GNU Fortran?.
* GETARG() intrinsic: Main Program Unit.
* getting started: Getting Started.
* GNU Back End (GBE): What is GNU Fortran?.
* GNU C required: General Problems.
* GNU Fortran command options: Invoking G77.
* GNU Fortran Front End (FFE): What is GNU Fortran?.
* GOTO statement: Assigned Statement Labels.
* groups of intrinsics: Intrinsics.
* hidden intrinsics: Intrinsics.
* Hollerith constants <1>: Character and Hollerith Constants.
* Hollerith constants <1>: Fortran Dialect Options.
* Hollerith constants <1>: Distensions.
* Hollerith constants <1>: Changes.
* Hollerith constants: Distensions.
* IARGC() intrinsic: Main Program Unit.
* IEEE conformance: Optimize Options.
* IMPLICIT CHARACTER*(*) statement: Disappointments.
* implicit declaration, warning: Warning Options.
* IMPLICIT NONE, similar effect: Warning Options.
* improvements, funding: Funding GNU Fortran.
* in-line code: What is GNU Fortran?.
* in-line compilation: Optimize Options.
* INCLUDE statement <1>: Preprocessor Options.
* INCLUDE statement <1>: Bug Reporting.
* INCLUDE statement: Directory Options.
* included files: Bug Reporting.
* inclusion, directory search paths for: Directory Options.
* incorrect diagnostics: What is GNU Fortran?.
* incorrect error messages: What is GNU Fortran?.
* incorrect use of language: What is GNU Fortran?.
* info, updating directory: Updating Documentation.
* initialization of local variables: Code Gen Options.
* INQUIRE statement: Missing Features.
* installation of binaries: Installation of Binaries.
* installation problems: Problems Installing.
* installation trouble: Trouble.
* installing GNU Fortran: Installation.
* installing, checking before: Pre-installation Checks.
* INTEGER type: Types.
* INTEGER*2 support: Missing Features.
* interfacing: Debugging and Interfacing.
* intrinsic functions: Fortran Dialect Options.
* intrinsic subroutines: Fortran Dialect Options.
* intrinsics, %DESCR() <1>: Extensions.
* intrinsics, %DESCR(): Changes.
* intrinsics, %LOC(): Extensions.
* intrinsics, %REF(): Extensions.
* intrinsics, %VAL(): Extensions.
* intrinsics, ABORT(): Fortran Dialect Options.
* intrinsics, AND: Missing Features.
* intrinsics, COMPLEX: Fortran Dialect Options.
* intrinsics, deleted: Intrinsics.
* intrinsics, disabled: Intrinsics.
* intrinsics, enabled: Intrinsics.
* intrinsics, EXIT(): Fortran Dialect Options.
* intrinsics, f2c: Fortran Dialect Options.
* intrinsics, FLUSH(): Fortran Dialect Options.
* intrinsics, Fortran 90: Fortran Dialect Options.
* intrinsics, GETARG(): Main Program Unit.
* intrinsics, groups: Intrinsics.
* intrinsics, groups of: Intrinsics.
* intrinsics, hidden: Intrinsics.
* intrinsics, IARGC(): Main Program Unit.
* intrinsics, LOC(): Extensions.
* intrinsics, MIL-STD 1753: Fortran Dialect Options.
* intrinsics, OR: Missing Features.
* intrinsics, SHIFT: Missing Features.
* intrinsics, side effects of: Fortran Dialect Options.
* intrinsics, SIGNAL(): Fortran Dialect Options.
* intrinsics, SYSTEM(): Fortran Dialect Options.
* intrinsics, UNIX: Fortran Dialect Options.
* intrinsics, VXT: Fortran Dialect Options.
* Introduction: Top.
* invalid assembly code: Bug Criteria.
* invalid input: Bug Criteria.
* KIND= notation: Types.
* known causes of trouble: Trouble.
* language dialect options: Fortran Dialect Options.
* language dialects: Dialects.
* language extensions: Extensions.
* language, incorrect use of: What is GNU Fortran?.
* LANGUAGES: Building gcc.
* large common blocks: But-bugs.
* large initialization: Large Initialization.
* ld can't find strange names: But-bugs.
* ld can't find _main: But-bugs.
* ld can't find _strtoul: General Problems.
* ld command: What is GNU Fortran?.
* ld error for f771: General Problems.
* ld error for user code: But-bugs.
* ld errors: But-bugs.
* legacy code: Collected Fortran Wisdom.
* length of source lines: Fortran Dialect Options.
* letters, lowercase: Case Sensitivity.
* letters, uppercase: Case Sensitivity.
* libf2c library: What is GNU Fortran?.
* libraries: What is GNU Fortran?.
* libraries, containing BLOCK DATA: Block Data and Libraries.
* libraries, libf2c: What is GNU Fortran?.
* line length: Fortran Dialect Options.
* linker errors: But-bugs.
* linking: What is GNU Fortran?.
* linking error for f771: General Problems.
* linking error for user code: But-bugs.
* LOC() intrinsic: Extensions.
* local equivalence areas: Local Equivalence Areas.
* LOGICAL type: Types.
* LOGICAL*1 support: Missing Features.
* loops, speeding up: Optimize Options.
* loops, unrolling: Optimize Options.
* lowercase letters: Case Sensitivity.
* machine code: What is GNU Fortran?.
* main program unit, debugging: Main Program Unit.
* main(): Main Program Unit.
* MAIN__(): Main Program Unit.
* MAP statement: Missing Features.
* maximum stackable size: Maximum Stackable Size.
* memory utilization: Large Initialization.
* merging distributions: Merging Distributions.
* messages, warning: Warning Options.
* messages, warning and error: Warnings and Errors.
* MIL-STD 1753: Fortran Dialect Options.
* missing bison: Missing bison?.
* missing makeinfo: Missing makeinfo?.
* missing debug features: Debugging Options.
* mistakes: What is GNU Fortran?.
* modifying g77: Unpacking.
* NAMELIST statement: Extensions.
* naming conflicts: Disappointments.
* native compiler: Installing f77.
* negative forms of options: Invoking G77.
* new users: Getting Started.
* newbies: Getting Started.
* null byte, trailing: Character and Hollerith Constants.
* number of trips: Loops.
* object code: Object Compatibility.
* octal constants: Dialects.
* OPEN statement: Missing Features.
* optimizations, Pentium: Unpacking.
* optimize options: Optimize Options.
* options to control warnings: Warning Options.
* options, -driver <1>: G77 and GCC.
* options, -driver: Invoking G77.
* options, -fGROUP-intrinsics-hide: Overly Convenient Options.
* options, -fcaller-saves: Optimize Options.
* options, -fcase-initcap: Fortran Dialect Options.
* options, -fcase-lower: Fortran Dialect Options.
* options, -fcase-preserve: Fortran Dialect Options.
* options, -fcase-strict-lower: Fortran Dialect Options.
* options, -fcase-strict-upper: Fortran Dialect Options.
* options, -fcase-upper: Fortran Dialect Options.
* options, -fdcp-intrinsics-delete: Fortran Dialect Options.
* options, -fdcp-intrinsics-disable: Fortran Dialect Options.
* options, -fdcp-intrinsics-enable: Fortran Dialect Options.
* options, -fdcp-intrinsics-hide: Fortran Dialect Options.
* options, -fdelayed-branch: Optimize Options.
* options, -fdollar-ok: Fortran Dialect Options.
* options, -fexpensive-optimizations: Optimize Options.
* options, -ff2c-intrinsics-delete: Fortran Dialect Options.
* options, -ff2c-intrinsics-disable: Fortran Dialect Options.
* options, -ff2c-intrinsics-enable: Fortran Dialect Options.
* options, -ff2c-intrinsics-hide: Fortran Dialect Options.
* options, -ff2c-library: Code Gen Options.
* options, -ff90: Fortran Dialect Options.
* options, -ff90-intrinsics-delete: Fortran Dialect Options.
* options, -ff90-intrinsics-disable: Fortran Dialect Options.
* options, -ff90-intrinsics-enable: Fortran Dialect Options.
* options, -ff90-intrinsics-hide: Fortran Dialect Options.
* options, -ff90-not-vxt: Fortran Dialect Options.
* options, -ffast-math: Optimize Options.
* options, -ffixed-line-length-N: Fortran Dialect Options.
* options, -ffloat-store: Optimize Options.
* options, -fforce-addr: Optimize Options.
* options, -fforce-mem: Optimize Options.
* options, -ffree-form: Fortran Dialect Options.
* options, -finit-local-zero <1>: Overly Convenient Options.
* options, -finit-local-zero: Code Gen Options.
* options, -fintrin-case-any: Fortran Dialect Options.
* options, -fintrin-case-initcap: Fortran Dialect Options.
* options, -fintrin-case-lower: Fortran Dialect Options.
* options, -fintrin-case-upper: Fortran Dialect Options.
* options, -fmatch-case-any: Fortran Dialect Options.
* options, -fmatch-case-initcap: Fortran Dialect Options.
* options, -fmatch-case-lower: Fortran Dialect Options.
* options, -fmatch-case-upper: Fortran Dialect Options.
* options, -fmil-intrinsics-delete: Fortran Dialect Options.
* options, -fmil-intrinsics-disable: Fortran Dialect Options.
* options, -fmil-intrinsics-enable: Fortran Dialect Options.
* options, -fmil-intrinsics-hide: Fortran Dialect Options.
* options, -fno-automatic <1>: Overly Convenient Options.
* options, -fno-automatic: Code Gen Options.
* options, -fno-backslash: Fortran Dialect Options.
* options, -fno-common: Code Gen Options.
* options, -fno-f2c <1>: Code Gen Options.
* options, -fno-f2c: Faster Programs.
* options, -fno-fixed-form: Fortran Dialect Options.
* options, -fno-ident: Code Gen Options.
* options, -fno-inline: Optimize Options.
* options, -fno-second-underscore: Code Gen Options.
* options, -fno-ugly-args: Warning Options.
* options, -fno-ugly-init: Warning Options.
* options, -fno-underscoring: Code Gen Options.
* options, -fpack-struct: Code Gen Options.
* options, -fpcc-struct-return: Code Gen Options.
* options, -fpedantic: Warning Options.
* options, -freg-struct-return: Code Gen Options.
* options, -frerun-cse-after-loop: Optimize Options.
* options, -fschedule-insns: Optimize Options.
* options, -fschedule-insns2: Optimize Options.
* options, -fset-g77-defaults: Overall Options.
* options, -fshort-double: Code Gen Options.
* options, -fsource-case-lower: Fortran Dialect Options.
* options, -fsource-case-preserve: Fortran Dialect Options.
* options, -fsource-case-upper: Fortran Dialect Options.
* options, -fstrength-reduce: Optimize Options.
* options, -fsymbol-case-any: Fortran Dialect Options.
* options, -fsymbol-case-initcap: Fortran Dialect Options.
* options, -fsymbol-case-lower: Fortran Dialect Options.
* options, -fsymbol-case-upper: Fortran Dialect Options.
* options, -fsyntax-only: Warning Options.
* options, -fugly <1>: Overly Convenient Options.
* options, -fugly: Warning Options.
* options, -funix-intrinsics-delete: Fortran Dialect Options.
* options, -funix-intrinsics-disable: Fortran Dialect Options.
* options, -funix-intrinsics-enable: Fortran Dialect Options.
* options, -funix-intrinsics-hide: Fortran Dialect Options.
* options, -funroll-all-loops: Optimize Options.
* options, -funroll-loops: Optimize Options.
* options, -fversion: Overall Options.
* options, -fvxt-intrinsics-delete: Fortran Dialect Options.
* options, -fvxt-intrinsics-disable: Fortran Dialect Options.
* options, -fvxt-intrinsics-enable: Fortran Dialect Options.
* options, -fvxt-intrinsics-hide: Fortran Dialect Options.
* options, -fvxt-not-f90: Fortran Dialect Options.
* options, -fzeros: Code Gen Options.
* options, -g: Debugging Options.
* options, -I-: Directory Options.
* options, -Idir: Directory Options.
* options, -pedantic: Warning Options.
* options, -pedantic-errors: Warning Options.
* options, -v: G77 and GCC.
* options, -W: Warning Options.
* options, -Waggregate-return: Warning Options.
* options, -Wall: Warning Options.
* options, -Wcomment: Warning Options.
* options, -Wconversion: Warning Options.
* options, -Werror: Warning Options.
* options, -Wformat: Warning Options.
* options, -Wid-clash-LEN: Warning Options.
* options, -Wimplicit: Warning Options.
* options, -Wlarger-than-LEN: Warning Options.
* options, -Wparentheses: Warning Options.
* options, -Wredundant-decls: Warning Options.
* options, -Wshadow: Warning Options.
* options, -Wsurprising: Warning Options.
* options, -Wswitch: Warning Options.
* options, -Wtraditional: Warning Options.
* options, -Wuninitialized: Warning Options.
* options, -Wunused: Warning Options.
* options, code generation: Code Gen Options.
* options, debugging: Debugging Options.
* options, dialect: Fortran Dialect Options.
* options, directory search: Directory Options.
* options, GNU Fortran command: Invoking G77.
* options, negative forms: Invoking G77.
* options, optimization: Optimize Options.
* options, overall: Overall Options.
* options, overly convenient: Overly Convenient Options.
* options, preprocessor: Preprocessor Options.
* OR intrinsic: Missing Features.
* order of evaluation, side effects: Non-bugs.
* ordering, array: Arrays.
* overall options: Overall Options.
* overflow: Warning Options.
* overly convenient options: Overly Convenient Options.
* packages: Unpacking.
* PARAMETER statement: Missing Features.
* parameters, unused: Warning Options.
* patch files: General Problems.
* patch files, creating: Merging Distributions.
* pedantic compilation: Pedantic Compilation.
* Pentium optimizations: Unpacking.
* POINTER statement: Missing Features.
* pre-installation checks: Pre-installation Checks.
* preprocessor <1>: Bug Reporting.
* preprocessor <1>: What is GNU Fortran?.
* preprocessor: Overall Options.
* preprocessor options: Preprocessor Options.
* prerequisites: Prerequisites.
* printing version information <1>: Overall Options.
* printing version information: What is GNU Fortran?.
* problems installing: Problems Installing.
* procedures: Procedures.
* PROGRAM statement: Main Program Unit.
* programs, cc1: What is GNU Fortran?.
* programs, cc1plus: What is GNU Fortran?.
* programs, compiling: G77 and GCC.
* programs, cpp <1>: Bug Reporting.
* programs, cpp <1>: What is GNU Fortran?.
* programs, cpp <1>: Overall Options.
* programs, cpp: Preprocessor Options.
* programs, f771: What is GNU Fortran?.
* programs, speeding up: Faster Programs.
* questionable instructions: What is GNU Fortran?.
* quick start: Quick Start.
* REAL type: Types.
* recent versions <1>: Changes.
* recent versions: News.
* RECORD statement: Missing Features.
* reporting bugs: Bugs.
* requirements, GNU C: General Problems.
* RETURN statement <1>: Functions.
* RETURN statement: Alternate Returns.
* return type of functions: Functions.
* row-major ordering: Arrays.
* run-time library: What is GNU Fortran?.
* run-time options: Code Gen Options.
* SAVE statement: Code Gen Options.
* search path: Directory Options.
* searching for included files: Directory Options.
* semicolons: Extensions.
* separate distributions: Merging Distributions.
* SHIFT intrinsic: Missing Features.
* side effects: Fortran Dialect Options.
* side effects, order of evaluation: Non-bugs.
* SIGNAL() intrinsic: Fortran Dialect Options.
* signature of procedures: Procedures.
* slow compiler: Large Initialization.
* source code <1>: Case Sensitivity.
* source code <1>: What is GNU Fortran?.
* source code <1>: Unpacking.
* source code: Source Form.
* source file: What is GNU Fortran?.
* source file form: Fortran Dialect Options.
* source file format <1>: Fortran Dialect Options.
* source file format <1>: Case Sensitivity.
* source file format: Source Form.
* source form: Source Form.
* source tree: Unpacking.
* speed, compiler: Large Initialization.
* speeding up loops: Optimize Options.
* speeding up programs: Faster Programs.
* standard support: Standard Support.
* statement labels, assigned: Assigned Statement Labels.
* statements, ACCEPT: Missing Features.
* statements, ASSIGN: Assigned Statement Labels.
* statements, BLOCK DATA <1>: Disappointments.
* statements, BLOCK DATA: Block Data and Libraries.
* statements, CLOSE: Missing Features.
* statements, COMMON <1>: Disappointments.
* statements, COMMON: Common Blocks.
* statements, DATA: Code Gen Options.
* statements, DIMENSION <1>: Adjustable Arrays.
* statements, DIMENSION: Arrays.
* statements, DO <1>: Loops.
* statements, DO: Warning Options.
* statements, ENTRY: Alternate Entry Points.
* statements, EQUIVALENCE: Local Equivalence Areas.
* statements, FORMAT: Missing Features.
* statements, FUNCTION <1>: Functions.
* statements, FUNCTION: Procedures.
* statements, GOTO: Assigned Statement Labels.
* statements, IMPLICIT CHARACTER*(*): Disappointments.
* statements, INCLUDE <1>: Directory Options.
* statements, INCLUDE <1>: Preprocessor Options.
* statements, INCLUDE: Bug Reporting.
* statements, INQUIRE: Missing Features.
* statements, MAP: Missing Features.
* statements, NAMELIST: Extensions.
* statements, OPEN: Missing Features.
* statements, PARAMETER: Missing Features.
* statements, POINTER: Missing Features.
* statements, PROGRAM: Main Program Unit.
* statements, RECORD: Missing Features.
* statements, RETURN <1>: Alternate Returns.
* statements, RETURN: Functions.
* statements, SAVE: Code Gen Options.
* statements, separated by semicolon: Extensions.
* statements, STRUCTURE: Missing Features.
* statements, SUBROUTINE <1>: Procedures.
* statements, SUBROUTINE: Alternate Returns.
* statements, TYPE <1>: Dialects.
* statements, TYPE: Missing Features.
* statements, UNION: Missing Features.
* straight build: Straight Build.
* STRUCTURE statement: Missing Features.
* SUBROUTINE statement <1>: Procedures.
* SUBROUTINE statement: Alternate Returns.
* subroutines: Alternate Returns.
* subroutines, intrinsic: Fortran Dialect Options.
* suffixes, file name: Overall Options.
* support for gcc versions: Merging Distributions.
* support for ANSI FORTRAN 77: Standard Support.
* support, gdb: But-bugs.
* support, f77: Non-bugs.
* support, Fortran 90: Missing Features.
* suppressing warnings: Warning Options.
* symbol names <1>: Names.
* symbol names: Fortran Dialect Options.
* symbol names, transforming: Code Gen Options.
* symbol names, underscores: Code Gen Options.
* syntax checking: Warning Options.
* SYSTEM() intrinsic: Fortran Dialect Options.
* tab characters: Source Form.
* texinfo: Updating Documentation.
* trailing null byte: Character and Hollerith Constants.
* transformation of symbol names: Names.
* transforming symbol names: Code Gen Options.
* translation of user programs: What is GNU Fortran?.
* trips, number of: Loops.
* TYPE statement <1>: Missing Features.
* TYPE statement: Dialects.
* typeless constants: Changes.
* types, COMPLEX: Types.
* types, constants: Constants.
* types, DOUBLE COMPLEX: Types.
* types, DOUBLE PRECISION: Types.
* types, file: Overall Options.
* types, INTEGER: Types.
* types, LOGICAL: Types.
* types, of data: Types.
* types, REAL: Types.
* ugly features <1>: Distensions.
* ugly features: Warning Options.
* undefined behavior: Bug Criteria.
* undefined function value: Bug Criteria.
* undefined reference (_main): But-bugs.
* undefined reference (_strtoul): General Problems.
* underscores: Code Gen Options.
* uninitialized variables <1>: Warning Options.
* uninitialized variables: Code Gen Options.
* UNION statement: Missing Features.
* UNIX intrinsics: Fortran Dialect Options.
* unpacking distributions: Unpacking.
* unrecognized file format: What is GNU Fortran?.
* unresolved reference (various): But-bugs.
* unrolling loops: Optimize Options.
* unsupported warnings: Warning Options.
* unused arguments: Warning Options.
* unused dummies: Warning Options.
* unused parameters: Warning Options.
* unused variables: Warning Options.
* updating info directory: Updating Documentation.
* uppercase letters: Case Sensitivity.
* user-visible changes: Changes.
* variables, initialization of: Code Gen Options.
* variables, uninitialized <1>: Warning Options.
* variables, uninitialized: Code Gen Options.
* variables, unused: Warning Options.
* version information, printing <1>: What is GNU Fortran?.
* version information, printing: Overall Options.
* versions of gcc: Merging Distributions.
* versions, recent <1>: Changes.
* versions, recent: News.
* VXT extensions: Dialects.
* VXT features <1>: Dialects.
* VXT features: Fortran Dialect Options.
* VXT intrinsics: Fortran Dialect Options.
* warning messages: Warning Options.
* warnings: What is GNU Fortran?.
* warnings vs errors: Warnings and Errors.
* warnings, all: Warning Options.
* warnings, extra: Warning Options.
* warnings, implicit declaration: Warning Options.
* warnings, unsupported: Warning Options.
* why separate distributions: Merging Distributions.
* wisdom: Collected Fortran Wisdom.
* writing code: Collected Fortran Wisdom.
* zero byte, trailing: Character and Hollerith Constants.
* _strtoul: General Problems.
Tag Table:
Node: Top
Node: Copying
Node: Contributors
22331
Node: Funding
25183
Node: Funding GNU Fortran
27701
Node: Look and Feel
30520
Node: Getting Started
31037
Node: What is GNU Fortran?
33370
Node: G77 and GCC
42922
Node: Invoking G77
44288
Node: Option Summary
46377
Node: Overall Options
50422
Node: Fortran Dialect Options
53759
Node: Warning Options
61505
Node: Debugging Options
70141
Node: Optimize Options
70989
Node: Preprocessor Options
73251
Node: Directory Options
74001
Node: Code Gen Options
75250
Node: Environment Variables
82351
Node: News
82824
Node: Changes
107364
Node: Language
113636
Node: Standard Support
115169
Node: Extensions
117580
Node: Types
120540
Node: Constants
125025
Node: Source Form
126194
Node: Pedantic Compilation
130041
Node: Case Sensitivity
133433
Node: Intrinsics
142015
Node: Dialects
145294
Node: Object Compatibility
146954
Node: Dropping f2c Compatibility
149280
Node: Other Compilers
152061
Node: Distensions
153848
Node: Installation
156193
Node: Prerequisites
157346
Node: Problems Installing
161898
Node: General Problems
162542
Node: Cross-compiler Problems
165629
Node: Quick Start
167661
Node: Complete Installation
175650
Node: Unpacking
176245
Node: Merging Distributions
179359
Node: Installing f77
184604
Node: Installing f2c
185964
Node: Patching GNU Fortran
188904
Node: Where to Install
190154
Node: Configuring gcc
193405
Node: Building gcc
195192
Node: Bootstrap Build
197214
Node: Straight Build
199137
Node: Pre-installation Checks
200541
Node: Installation of Binaries
203765
Node: Updating Documentation
205125
Node: Missing bison?
205961
Node: Missing makeinfo?
207328
Node: Distributing Binaries
207868
Node: Settings
213578
Node: Maximum Stackable Size
214425
Node: Floating-point Bit Patterns
215006
Node: Large Initialization
215767
Node: Alpha Problems
217364
Node: Debugging and Interfacing
218443
Node: Names
221016
Node: Main Program Unit
224077
Node: Arrays
226434
Node: Procedures
229776
Node: Adjustable Arrays
232152
Node: Alternate Returns
235025
Node: Functions
235912
Node: Common Blocks
237547
Node: Local Equivalence Areas
238722
Node: Alternate Entry Points
240241
Node: Assigned Statement Labels
247022
Node: Collected Fortran Wisdom
248876
Node: Overly Convenient Options
250327
Node: Block Data and Libraries
253327
Node: Faster Programs
255741
Node: Working Programs
257364
Node: Loops
260047
Node: Advantages Over f2c
265266
Node: Language Extensions
266171
Node: Compiler Options
266693
Node: Compiler Speed
267160
Node: Program Speed
267884
Node: Ease of Debugging
269182
Node: Character and Hollerith Constants
271635
Node: Trouble
272444
Node: But-bugs
273911
Node: GPC Bugs
279044
Node: Missing Features
283336
Node: Disappointments
297381
Node: Non-bugs
299795
Node: Warnings and Errors
311379
Node: Open Questions
313078
Node: Bugs
314381
Node: Bug Criteria
315786
Node: Bug Lists
318047
Node: Bug Reporting
318832
Node: Sending Patches
332259
Node: Service
337756
Node: Index
338230
End Tag Table